So the removal of OP_RETURN size limit will allow for larger data payloads to be embedded into Bitcoin transaction,
Ah, but it doesn't instead of using op_returns the data stuffer can just use 'fake addresses', outputs that look spendable but aren't and people are doing that today. This bloats the utxo set.
which potentally could lead to significant increase in the blockchain size, unlike witness data wich can be pruned in segwit tx's the OP_RETURN data is stored in the UTOX
Op_return data is entirely pruned that's why it was 'created' as an alternative to using outputs that look spendable.
Larger OP_RETURN outputs could amplify existing attack vectors, such as mempool spam or flood-and-loot attacks, as noted by commenter Brazy Development in the pull request.
The discussion there immediately points out that this point was incorrect. Someone who wants to dump a lot of data in transactions can just use 'fake addresses', it adds size exactly as well, it's impossible to block and it has the exacerbating factor of being unprunable.
the market for block space and existing node defenses like fee based eviction mitigate these risks. It's being claimed attackers would face high economic costs.
This is irrelevant, it's an argument about not worrying about spam but for it to be relevant the proposal would have to increase the potential for spam, and it doesn't (again, the attacker can just use ordinary outputs to bloat their transactions).
The frustration everyone feels with developers “playing with people’s money” by adding complexity is a common sentiment among Bitcoin maximalists.
Then good news, this proposal strictly decreases the complexity of the bitcoin software, and also decreases complexity for people trying to write software that uses it (because it eliminates some limit they could accidentally hit).
Do these points change your thinking at all?