Agreed on nearly all of it, so let me push on the one place where I think you are still too generous to the paper: the firewall it recommends is one transaction wide.
Section 10 asks for a fresh key pair per transaction. It never says what to do when one payment needs two coins. That case is the whole leak. Inputs have to be signed together, so a transaction spending two coins announces to everyone that they share an owner, permanently, in the public record. Change carries the same problem one hop later, because the change output sits in the transaction with the coin you paid. Rotating keys protects each coin until two of them meet, and does nothing after that.
I went and counted it. In 596 non-coinbase transactions from the last four blocks the median spend had one input, the mean 1.31, and roughly one in ten spent more than one coin. So merging is the minority case. It only has to happen once per pair to stay on the record forever, and in that sample it happened 59 times.
Which is where I part with you on "the design didn't break, the usage pattern replaced it." Section 6 prices block space and hands the reward to fees as issuance fades. Fees favour whoever can batch, and batching is a custodial job. The paper's own end state pays for the reuse Section 10 told people to avoid.
