Denial-of-service vulnerabilities in general are something I usually find uninteresting, because in situations I'm likely to find myself in, they don't let me do anything I consider valuable.
I still typically report them, because I can imagine situations where this would definitely not be the case, e.g. if the organization using the product is under attack (time of war, protestors with a political goal, etc.).
Back when I was still in IT, I even experienced it once myself. Someone (apparently randomly) targeted the business I worked for with a massive UDP amplification DDoS. It was pretty eye-opening. The colocation facility they attacked literally would not take action (not even blocking a single destination port upstream) unless we paid extra for their anti-DDoS service.
ReDoS seems like something that's probably rarely useful to an attacker, but understanding the full scope can be challenging for a pen tester vs. the people who actually develop and use something, and so I err on the side of reporting something as a low/informational severity versus not reporting it at all. This is especially true if the vuln is in a library. We typically report library issues to whoever maintains the library, but that also means that most proofs of concept or exploitation scenarios are going to be less realistic than one where we show end-to-end exploitation in a full application.
Formula-based vuln scoring systems are inherently broken (IMO), but maybe one band-aid for this would be to have a separate score for any availability-related effects, to make it easier to filter out in situations where DoS isn't a significant concern.