It can be optimized locally. If you do that on consensus level, then people will be mad, and they will spam more. If you do it locally, then your node will be safe, and everyone else will process the spam.

So, it is not about doing nothing. It is about making local optimizations, and convincing users to use your version.

If you block it on consensus level, then people will start making transactions, which will be valid under old rules, and invalid under your new BIPs. Which means, that then you risk using a minority chain.

A soft-fork can be "soft", if deployed correctly. Otherwise, everyone could deploy a soft-fork every day. But that would result in a lot of minority chains.

And, as far as I know, the filter enthusiasts don't have hashrate majority on their side. And as long as it is the case, using a minority chain is more harmful, than following the strongest one.

If you remove something, which is considered as valid by other nodes, then you will end up on an altcoin. The only safe way, is to give some data a lower priority. Because then, you can mark 1BitcoinEaterAddressDontSendf59kuE as "very difficult to spend", and place it on the end of your processing queue. Then, things will be faster, if validating such things will be delayed by your node. However, if you reject it instead, then after many years, someone may produce a valid transaction, and fork you out of the network.

For example to know, that you are not using a minority chain. SPV nodes can be tricked, to follow the wrong chain. We had cases, when big mining pools stopped verifying things, and there were some block reorgs because of that.

My node does not process the spam. Anyone can use implementation like utreexo, and don't store things like that. It is just not the default.

But if you use Core or Knots, then you store and process historical transactions, so it is your choice. Even Knots cannot address historical spam, and does nothing about it.

If you assume 0.1 sat/vB, then it means 1 GB per sending 1 BTC. Which means 380 GB of potential spam. Is it too much? Well, the total size of the chain is around 700 GB. And, again, Knots does nothing to address that historical spam.

You can do a lot of things. But splitting the chain, where no-fork solutions are possible, is pointless.

No. But I believe that the first layer will be turned into that in the future. And then, users caring about resources will have to do their optimizations on lower layers, and process a subset of the mainnet traffic.

Because if you are going to process 100% of the mainnet traffic, then you will be spammed, even if you use Knots. Just because people will always bypass all filters, and stuff their data into historical blocks, which you will never touch, just because you don't want to.