>>Maybe I missed something, but why does this change require a hard fork?
I guess you are right that it doesn't technically require a hard fork, but I see this proposal as more likely being merged with other hard fork or soft fork features. It depends on which upgrades are happening at the time. If there's a specific soft fork being proposed to merge this proposal with, I can update it.
>> I'm also concerned about the coordination required to get into The One OP_RETURN Per Block, as this certainly requires some measure of centralization of that Merkle Tree construction.
This will be discussed further in a future BIP, but the basic idea is that each miner can run an additional piece of software that builds the tree structure. It's much like submitting a transaction to the network today, if one of the miners does not accept it, another likely will.
>> Some of those OP_RETURN outputs have non-zero value. As such, those outputs are provably unspendable, and they are essentially paying the rest of the coin holders via supply deflation.
Good point, there are other ways to do proof of burn.
>> Finally, Bitcoin nodes may safely discard OP_RETURN outputs at any time, since they are unspendable. Thus, nodes can clear a few GB of disk space whenever they need it, but that data is less than 1% of the total chain size at the time of writing.
Yes, but that doesn't affect IBD.