Eh. That’s kinda like “don’t put all your money in dollars”

If the US Dollar goes to zero or the only rendering engine bit rots, other things are happening such that I won’t be too concerned about not having money or not being able to browse the web.

No, it's really not. It's more like "don't put your money in one stock," but it's much more like "architect your code sanely."

In general, if I have a modular abstraction barrier in my code, I try to have at least two implementations. For example, if I have a generic key-value store so I can switch databases later, I'll make an implementation for e.g. PostgreSQL and redis. That way, I don't accidentally couple to one or the other. Otherwise, I'm fooling myself.

That's just basic software engineering, but for open industry standards, it's really critical. You don't want CSS rendering depending on some browser bug or quirk. It's critical to have multiple implementations, or it's not a standard.

The flip side of allowing multiple implementations also means it's possible to build things like web crawlers, screen readers, and other technologies without spending millions of dollars re-engineering IE or Chrome to be identical, bug-for-bug. It's also possible to build new things we never imagined. Indeed, we had a lot more diversity in HTML 2.0 days, when things were simple enough that anyone could build a novel web technology over a weekend (with full HTML 2.0 parsing).

(Before I get accused of over-engineering, I usually don't have these types of modular abstractions; if I don't expect to ever swap databases, I'll e.g. code to PostgreSQL directly