Attackers can be quite ingenious, and don't forget that I'm also thinking about attackers who already have access to your machine and can run some setuid program that you've written that you think is the only thing with access to some file or data.
Even without that — let's say we're talking server development — imagine if the server can somehow be coerced into reading an attacker-chosen file (which on Linux might include something in /proc, so potentially any file descriptor the process has open too). Historically these kinds of bugs have been quite common, and if I can also crash the server, then I'm in good shape to read both the crash logs and generate crashes…
I spend a fair bit of my time debugging things from just backtraces, so I'm aware of how difficult it is. It is, however, a million times harder if all you have is sh: illegal instruction or similar, since that tells you almost precisely nothing about what went wrong, which is why we've added the new backtracing feature to Swift 5.9.
i think it really depends on a particular service’s threat model. for swiftinit, once we considered all the possible reasons (animosity, preservation of monopoly, stealing user information, hijacking the server’s identity, etc.) someone could target the site, we concluded that denial of service eclipses virtually all other types of threats to us.
denial of service, of course, doesn’t require obtaining any sensitive information about the server. if anything, lack of backtraces makes the site more vulnerable to denial of service by making it harder to fix problems.
As an aside, this is why virtually all server best practice guides will recommend running some sort of reverse proxy in front of your actual service, especially when it's exposed publicly. That way the proxy (often nginx) handles connection termination on the privileged ports and the actual service can run fully unprivileged.