"Denial of service" is never a security bug; it's a huge mistake people have started classifying these things as such to start with. Serious bug? Sure. Loss of security? Not really.
That very much depends on what service is being denied. Nginx is _everywhere_. While not a direct security concern for nginx (instead an availablity issue) it could have security or safety implications for wider systems. What if knocking out nginx breaks a service for logging & monitoring security information? Or an ambulance call out management system? Or a payment progressing system for your business at the busiest time if your trading year? There are many other such examples. This sort of thing is why availablity can be considered a security matter and therefore why DoS vulnerabilities, particularly those affecting common software, are handled as security issues of significant severity.
With fairly cheap ddos services you can "just" order you can knock most servers offline anyway. Internet reachability is rarely safety-critical, and if it is, that's probably a huge design flaw somewhere because there's tons of reasons outside of your control that can make the internet not work for either the server or clients.
Is all of this inconvenient and (potentially) a serious problem? Sure. But not "zomg criminals have credit card records / can spoof random domains / read private data / etc. etc." type serious.
A DoS bug and an DDoS attack are very different things. One is a flaw that can bring a service down, the other is a brute force technique for making a service unusable. You can DDoS services without exploiting bugs.
Viewed in this light a bug that enables a successful Denial of Service (DoS) or Distributed Denial of Service (DDoS) attack is a security bug. A bug that causes a DoS or DDoS, but is not exploitable, would not be a security bug (e.g., some idiot added an infinite loop to the startup code). That's where issue triage comes in, a bug should never be assigned before its triaged. Sometimes triage results in 'we don't know enough' and someone gets assigned to evaluate the bug to answer specific questions before triage can finished. After triage is get assigned - or even better, a developer with a matching skill set chooses it to work on for the next release/sprint/etc.
But I agree DoS is kind of a strawman since everything connected to a network is vulnerable to some form of DoS without extensive mitigation.
What about serving certificate revocation list, with another system relying on say one day old cache? (Sure, that's "fail open" - but still...).
Or proxying LDAP for sync to a central auth/authz system?
Ed: proxy giving access to logging system goes down - alert on failed logins silenced, disabling rate limits for brute force attacks?