Wouldn't it then be "cleaner" to simply do a softfork with a new transaction format which already includes the UTXO proof?
Of course it would be. But the default option is to "do nothing", so expect that option to be deployed, unless someone will propose something else.
but I was referring to the phase before the acceptance into a block, when the transaction is trying to propagate via the mempools
If some transaction has enough information, that it is accepted in a block, then what else is needed, if it is flying in mempools?
Perhaps Core in v31 returns to the old standardness values too.
It is hard to put limits back, when they are lifted. Nobody would accept that, for the same reason, why nobody would rise minimal fees from 0.1 sat/vB into 1 sat/vB or 10 sat/vB.
Introducing standardness rules was easy during early days, because there were not so many nodes. But now, if non-standard transactions will be widely included, then in practice, we would need a new way of upgrading things (fortunately, there are some, but they are unused, because it is easier to increase Segwit version, at least for now).
That would lead to an UTXO set explosion.
It is not a question, if UTXO set will explode. The only question is "when?".
that you will only be able to make transactions without friction if you already include the UTXO proof
Yes, so aware users should be prepared for that now, by saving more things than just their private keys in their backups. And unaware users will of course suffer. And then, only spammers can be blamed, because they are pushing us to the world, where accepting UTXO proofs is inevitable, when there is too much spam.
Being your own bank comes with some responsibility. Users should watch quantum progress, users should keep their transaction data somewhere, users should not use too far in the future locktimes, to not risk their funds being burned forever, and so on. That is a price you have to pay for P2P transactions: that you have to care about consensus rules, and the current state of the network.