There's still ways to make nasty blocks.
Blocks as small as 8mb that would take >10 mins to verify, and radically expand the UTXO dataset. It isn't as though we are out of the woods. The economic incentive to do something like this is that the miner could be building on it immediately whereas everyone else is still verifying, (or they just skip doing that, which fine but brings its own set of issues).
Honestly, I'm the last person who wants to see the limit increased and a host of other problems appear. My original opinion was that an adaptive, dynamic block size limit was best, just like you argued all along. It was only when Gavin preferred a fixed scheduled increasing limit that I went with that, for the reason that any workable solution to the 1MB is better than no solution at all, and finally we are seeing with BIP 102 what must be the lowest common denominator in this whole saga. Even BIP 102 is a hell of a lot better than doing nothing.
Regarding >10 mins verification. Those monster tx of nearly 1MB took a lot of people by surprise, except Core Dev who knew about this risk and had a 100KB relay limit. Unfortunately the "nasty" 25 sec verification tx were out-of-band and fed directly into Discus Fish. Maybe tx size should be limited to 10% of block size at the protocol level and this needs to go in with any >1MB change?
I really like the anti-fragility aspect of Bitcoin which is amazing because every curve ball sent its way gets dealt with in the software making it stronger in the future.
I am not yet convinced that forking the network for a 1MB change to the block size is "better than doing nothing".