It's a nice idea actually and I think I like it. It's basically a voluntary UTXO snapshot system for faster sync but I think the main issue is kinda more of trust and incentives since basically the OP_RETURN snapshots aren’t actually enforced by consensus, nodes can’t fully trust them without already trusting whoever created them.
Indeed, the incentive issue for correct OP_RETURNs with hashes is the main problem of that approach. Thinking a bit about it, such a system could work in theory like an optimistic rollup, i.e. the fake OP_RETURNs could be "challenged" by other nodes and then invalidated by other nodes. But to really incentivize that behaviour you probably would need an altcoin (just like optimistic rollups) to be able to pay nodes for correct OP_RETURNs. That could be made without any additional blockchain, perhaps with RGB or Taproot Assets, or an old-style protocol like Counterparty or Runes. It could also be made with a sidechain. But it has to be seen if that altcoin's value can get so high that it really incentives nodes in a way that the end security for nodes trusting in that approach is "better", i.e. more secure, than a SPV approach (Electrum etc.).
Downloading from an 'Armaggedon' Node, although verifiable would in my eyes make it as bad for Security as running the Node of a Blockchain that has just had its Genesis a couple hundred Blocks ago.
That's why I would propose in this case to require always two or three Armageddon blocks on each node, at least those participating in the OP_RETURN submitting approach. One Armageddon can fail but two in a row is extremely unlikely to get undiscovered - and of course everything what can be done with the SPV approach would still be present.
One of the purposes of the Blockchain growing more and more is particularly that, to make things less easier to forge every time a Block is added to it.
I don't know if I agree with that statement. 6 confirmations are currently considered "good enough" to prevent a reorg. A couple of thousand of blocks are almost impossible to forge.
It also adds too much comfort for users in a situation where Security should be prioritized. When setting up a new Node, people will be tempted to pick Armaggedon over Full Node for reasons of comfort which may in time lower the number of Full Nodes. In my opinion, it is best that we have only the 'extremes' as in SPV and Full Node. Making an option in between, will the advantage of not having to be patient to sync the entire Blockchain be worth the disadvantages?
Well we have already ZeroSync, even if it's still alpha, and we have pruned nodes, both intermediate approaches for nodes. I'm not sure if the "voluntary Armageddon approach" is better or worse than ZeroSync. On a first glance I would probably prefer ZeroSync because the incentive problem seems to have been solved more elegantly, but the Armageddon approach may be easier to understand for non-technical people and thus also could have its audience.
I believe in reality that this approach could be more of an alternative for SPV users (it should require the same amount of resources, perhaps a little bit more disk space) than for full node users. The "worth" of the "Armageddon nodes" for the network would be approximately similar to the pruned nodes (recent transactions can be requested from them) and the privacy is
much higher than with SPV. In fact this model could challenge important chain analysis techniques like running Electrum servers (but ZeroSync does that too).
