Correct, I agree you run it with an eye on it (which you should probably do anyway) instead of firing and forgetting (which, to nginx's credit, is typically stable enough you can do that just fine).

That said, nginx treats experimental as something you explicitly run in production- when they announced they added it into experimental they actually specifically say to run it in prod in an A/B setup.

https://www.nginx.com/blog/our-roadmap-quic-http-3-support-nginx/

Nnnnnot really? Nginx literally asks for people to do that. Here they are announcing that experimental QUIC/HTTP3 support: https://www.nginx.com/blog/our-roadmap-quic-http-3-support-nginx/

You'll notice they literally outright ask

• If you run large‑scale Internet services, experiment with A/B testing by deploying nginx-quic for some users or some services.

They literally ask for you to try it in production, so... yeah, you're supposed to use this experimental feature in prod. As for 'run it carefully', just that- don't just fire it off and assume all is good, keep an eye on it like the say. A/B deploy it, see how it works, and let NGINX know if you happen to run into anything.

1. I'm glad we agree a DoS is a vulnerability.
2. CVE best practices state that CVEs are required to be assigned to experimental features. F5's company policy is that CVE best practices are followed. F5 is the company that owns nginx. Therefore, it was required. Nice 'legal requirement' strawman. Also, 'Common' in this situation is not defined as 'Widespread; prevalent,' it's defined as 'Of or relating to the community as a whole; public.'
3. That was a typo regarding 'stable,' my bad. I meant to say 'It is just not available on stable, but is both via commercially and via the open source version.' However, it's still available on commercial versions and open source, and 'non-stable' versions are not inherently unstable, they're just called 'mainline'. Proof: https://nginx.org/en/download.html Stable is basically just 'long term support/LTS' versions of nginx.
4. Again, you are intentionally misusing the definitions of the word common. Lets see what MITRE has to say about it, hmm?

Common Vulnerabilities and Exposures (CVE) is a dictionary of common names (i.e., CVE Identifiers) for publicly known information security vulnerabilities. CVE's common identifiers make it easier to share data across separate network security databases and tools, and provide a baseline for evaluating the coverage of an organization's security tools. If a report from one of your security tools incorporates CVE Identifiers, you may then quickly and accurately access fix information in one or more separate CVE-compatible databases to remediate the problem.

Source: https://cve.mitre.org/about/

5. Yes, I would consider notifying the development mailing list as 'quietly' fixing it, as most all companies using it will not be on the development mailing list. It's meant to be an area for developers to discuss things. They didn't inform the public, they informed the devs.
6. Where are you getting database from? You've randomly pivoted into talking about database transactions then started babbling about how you somehow think using a production mainline release with production options on a fully supported commercial binary is somehow inherently unsafe, as though it wouldn't still be in dev or test.

Since you seem to have no idea about how web servers work, or indeed, experimental features, I'll let you in on a secret- The only difference between a non-experiemntal option in nginx and an experimental option is that they're unsure if they want that feature in nginx, and are seeing how many people are actually using it/interested in, or they think that usage patterns of the feature might indicate another, better method of implementation. "Experimental" does not mean "unfinished" or "untested."

If you know nothing about programming, CVEs, or even web engines, please stop embarrassing yourself by trying to trumpet ill-thought out bad takes on subjects you don't understand.