Daniel is not saying that is a wrong thing. He is saying that he has a PR to review and would need a clearer spec for this and gives his opinion on how it can be improved. His opinion is interesting because he is a long time spec user and writer.
One commenter says that it's like the coca cola boss criticizing a competitor, but curl implements a lot of protocols. He probably doesn't care.
It's for fun, granted, but if you want curl to implement your fun project, part of the fun becomes doing things properly. If you bothered writing a spec, it might as well be unambiguous, no? Not that I think the point of Gemini is to be fun, mind you. I think it's a strongly political movement advocating for minimalism. I do believe it's a worthy cause.
His point is also to criticize the technical choices but that's fair game too. Again, his opinions as someone who has a lot of experience in the field are interesting too. Should I implement such a protocol now, I would definitely get back to this article to make sure I'm paying attention to the right things and making the right tradeoffs for my use case.
I overall think the Gemini community should take Daniel's input as a good contribution to their ecosystem. He took time to sit down and consider Gemini seriously. Several times.
Now he finds gemtext pages ugly, it's his opinion expressed on his personal blog, it's not particularly interesting and this opinion is not particularly related to his expertise. It's also not worth discussing with logical arguments since it's taste. Now there's still a point that can be made from this: if many people find Gemini ugly, including someone used to deal with RFCs daily, that means it will stay small. And that it's in the end, not an adequate answer for widespread minimalism it could have been and which is a goal that seems worth pursuing.