Never underestimate interoperability.
Personally I don't have much use for this attitude, the main problem I have with the web is when faced with the choice of empowering the publisher vs empowering the user, we kept on choosing to empower the publisher. The standards and browsers were owned by the web publishers, no one represented the user, and now instead of having a "user agent" installed on your machine to browse the web, you have a piece of spyware, better referred to as "Google's agent."
I don't really need to trade Google's Agent for Drew DeVault's Agent, give me software that does whatever I want it to do, fuck the publishers. But what do I matter, I'm not building any of this stuff.
But a community could form around early HTML, make clients and servers that only support early HTML, and vow to never support later HTML features. Such a community wouldn't be much different from Gemini's. Psychologically, they would have more difficulty rejecting new features (that have already been implemented), be less exciting initially (since they have less novelty), and have more trouble distancing themselves with mainstream HTML. But psychologically, Gemini is apparently reinventing the wheel without any advantages over HTML...and that disadvantage, at least to me, feels worse than the aforementioned advantages.
EDIT: I actually think gatekeeping a community with a different protocol may be a good idea. But I haven't heard about any technical advantages of Gemini (e.g. a protocol design that would be especially hard to extend, like a bloated spaghetti protocol on purpose) and I think that's a wasted opportunity. Nor have I heard about anything particularly interesting in the Gemini community, which makes me think the psychological benefit of a separate protocol isn't enough for an effective community, Gemini's community would need some other advantage, then perhaps a separate protocol wouldn't be necessary.