I am using ERC165Upgradable contract and whichever contract inherits from it, overrides supportsInterface if they wish so.
If the contract needs to be updated(needs some feature), dev updates supportsInterface function to include one more interface check and also adds the feature in the code.
Why would I ever need to inherit from ERC165StorageUpgradable ? It has a mapping that doesn't make sense. If the contract needs to have new interface registered, it means it needs to have the new feature code added to it, Just calling registerStandard is not enough because it means you are registering a new interface at any time, but the contract doesn't contain the code for this new feature interface.
I'd appreciate the reasoning behind this(what's the strong argument) to use ERC165StorageUpgradable ?
_registerInterface is an alternative to overriding supportsInterface. In addition to calling _registerInterface you would still have to implement the additional code required by the interface.
This was how OpenZeppelin implemented EIP165 a few years ago, before storage became too expensive and we moved away form it, but kept it for people who preferred it, as the API is a lot simpler than overrides.
Nowadays I don't think there's good reason to use this. The only one I can think of is if you have a ton of interfaces and overriding supportsInterface, which essentially results in a chain of ifs, goes over the 30k gas limit imposed by EIP-165. In that case storage may be better because it's constant time.