On that we agree: WAL+DB dead is a dead OSD.
I've seen a speculative outline on recovering the OSD but have not seen someone try.
And it's indeed a fair tradeoff: I'd expect the bad backend drives to die long before
Spinners often have a lower TBW and AFR than even low-endurance SSDs.
the enterprise write-intensive drives
Do you find that you strictly need high endurance SSDs? 99% of enterprise SSDs never use more than 15% of their rated endurance. These days write-intensive usually means Optane-replacement SLC. More common here is mixed-use, which is typically the very same hardware as a "read intensive" SSD just with more overprovisioning. If you really need more endurance than comes out of the box with an RI device, you can often adjust the OP yourself at much lower cost.
I have for wal+db. (or, in the case of spinning rust, I'd expect a mechanical failure long before a flash failure).
Most SSD failures are firmware and can be fixed in-situ. I've had to replace 4000 HDDs with a design flaw - scattered around the world. Nightmare
Thus, in the end, it's no different from a dedicated wal+db iff wal+db stays dedicated: I've seen people suggest to keep wal+db colocated if there's a fast flash in front of the drive, as wal+db would essentially always be hot in the cache.
Indeed I've read studies that claim a superset of benefits from a transparent cache compared to just WAL+DB.
(note: I know that the OSD thinks it directly talks to the crap drives,
Reads are always served from the slow device, and writes over a certain size go there directly. I've seen use-cases where the hassle of WAL+DB offload doesn't actually make an appreciable improvement.