That's a submission I made now 7 years ago that has both an article on the topic and a lot of good discussion.
Summary: Complex language at the time impeded compiler development. Compilers were not free (like C with Unix systems). People don't like being told what to do (Ada was initially mandated by DoD for new systems). The compilers remained very expensive into the 90s, by which time open source compilers were out there but the momentum was against Ada. Even after the open source compilers, commercial ones are still (today) very expensive.
As with all things government procurement, it solves yesterday’s problems tomorrow.
That mandate made sense with the 70s-80s model of big iron systems built in mainframes/vax/etc or other low change rate systems. It lowered the risk that the customer would lose control of the applications that it built.
That was and is a real problem. I’ve worked in various .gov roles outside of federal, and many key business systems have black boxes that nobody can edit or sole-source proprietary software from some long defunct company.
Ada as far as I know positioned itself for a niche of secure software. It is very popular in defence, aerospace etc sectors where secure and safe is critical. When I first looked at Ada sometime back it looked like throw back from the Pascal era. It looks like a mix of Pascal and Eiffel; it is very verbose.
When it came out it was very much perceived as a US military language. Because it was, developed by them to reduce the 'tower of babel' programming languages.
Regular people saw no reason to learn it, and at the time there was a high level of military distrust amongst the young.
The Ada mandate was from 1991-1997. It is still used on some newer systems developed after that, but largely the embedded real-time systems Ada was (particularly) meant to target have been developed in C, C++, and Fortran for DoD. These days, Ada is probably as common as Fortran and largely present more for historical reasons than deliberate ones with C and C++ being the dominant languages for DoD systems.
For non-real-time systems, for example IT system, the DoD has a preference for buying COTS (commercial off the shelf) software which will be whatever industry was using when that particular system was developed (so a variety of languages).
That said, the 787 (which I worked on briefly now over a decade ago) software was decidedly non-military and developers for the software were given a choice between C and Ada for their subsystems. It's out there in a variety of critical applications still, though it seems more popular in Europe than the US.
The usual answer is "safety with speed," but Ada doesn't have safe memory deallocation in core. (There's a proposal from 2018 to add it, based on Rust's approach and Rust's empirical success with that approach.) In other words, Ada doesn't protect you from use-after-free or double-free issues. You can bolt on a third-party garbage collector if you want, but now you have GC overhead. ("Safety with slightly less speed" has been dominated by Java for years, whose performance is competitive with ahead-of-time-compiled code for long-running processes.)
Ada's actual niche is safety with speed for constrained environments where you want to do static memory allocation anyway, like flight computers, train computers, nuclear power plant computers, etc. There's no need for the Engine object to be dynamically allocated - you've got two, or four, or whatever, depending on the model of airplane, and you're going to be doing years of testing before shipping software to that model of airplane, and the code will run on it for decades.
Which takes advantage of Ada's other in-practice niche - it has been a safety-with-speed-for-constrained-environment language for many decades. If you want to make your plane or train not crash, the best thing you can do is to start with existing plane/train software and modify it. And in turn the existing software is based on software that existed previously, going back decades, and decades ago Ada was the clear best answer. (In the rare cases where you write brand new software, you're going to need to do extensive design and testing work regardless of the language it's in to make sure it does the right thing - see also, MCAS.)
In other industries, there's no particular reason to develop on top of Ada and a lot of reason to use other, more featureful languages. If you're making version 2 of your video playback software or CSS engine or whatever, you're not going to start out by saying, version 1 was bug-free because we did rigorous testing for government certification, so let's start from version 1. You'd prefer to ship something that works well enough and iterate.
A whole lot of languages, including C and C++, addressed the use case of speed, development efficiency, and usability for dynamic / general-purpose environments. Newer languages like Rust and Go (and, again, Java in its own way) offered safety without compromising any of those three. To people who wanted those, Ada didn't have much to offer.
https://news.ycombinator.com/item?id=7824570
That's a submission I made now 7 years ago that has both an article on the topic and a lot of good discussion.
Summary: Complex language at the time impeded compiler development. Compilers were not free (like C with Unix systems). People don't like being told what to do (Ada was initially mandated by DoD for new systems). The compilers remained very expensive into the 90s, by which time open source compilers were out there but the momentum was against Ada. Even after the open source compilers, commercial ones are still (today) very expensive.