Of course it would be. But it is good to have a backup plan, if the community will reject your changes. And scripts like that can be used, to show with your own coins, that you support a given proposal. So, if you think that the block reward for block N is too low, then you can increase it, by timelocking coins to be spendable in that block or later (and, as you noticed: coins will be spendable by anyone, but miners could replace user-made transactions, and sweep them in the same way, as they can sweep funds from bc1pfeessrawgf, and also, even if funds could be claimed in later blocks, miners will probably try to get them as soon as possible, as long as it will be profitable to do so).

If you will use existing opcodes, like OP_CHECKLOCKTIMEVERIFY or OP_CHECKSEQUENCEVERIFY, then they will not have that option. The same if you timelock your transaction. For example: if you are a hodler, and you publish a transaction, which will give many coins to the miners through fees, but will be timelocked to block number N, then you could spend your coins before, and invalidate timelocked transaction, or you can wait, and see how miners will confirm your transaction in the future, and take fees out of it.

Also, you can try to convince the current miners, to accept a proposal, where they will send some of the current coinbase rewards to some future block numbers. Or: you can make a mining pool, which will produce such block templates, and try to encourage miners to join it. Then, by grabbing all fees from users, and producing one timelocked output per block, in the coinbase transaction, it will be more space efficient, than if you encourage single users to timelock their coins individually.