No. It introduces a condition without considering which nearly all currently-deployed contracts were written. This is exactly against opposite the rest of your post.
Operation of all contracts will have to be re-considered, and many (most?) will need to be rewritten, to answer a new question: “Who pays the rent?”
Either this, or some form of special-casing is introduced for “pre-rent” contracts; this increases system complexity a little, and incentivises “state hoarding” up until the feature is enabled (like described in this post). The latter can (probably) be worked around, but then it increases complexity greatly.
The problem is, we can’t reasonably expect both decentralisation and pay-once general storage.
Sharding (at best) delays this, and (at worst) allows a much more rapid growth.
Personally, I would much rather see exodus from the (future) Ethereum 1.x shard into rent-enabled shards, rather than the same free-for-all. At least if we’re to expect people to run PoS-enabled clients on their laptops. (Replace “shard” with “side-chain” if needed.)
Whether rent should be enabled on 1.x is (still) an open question, IMO. But it should be, eventually, somewhere. [All] costs should be internalised, otherwise the protocol will suffer a “tragedy of the commons”.