It was started in a situation where OpenSSL had bad security practices, a chaotic coding style and plenty of obsolete garbage. None of that is true any more.
If you look at the vuln posted here it's a sign how mature OpenSSL became: They rate it HIGH, but it's a rather insignificant vuln that will barely matter in practice.
I mean, I wouldn't be surprised if it lets you check a box on PCI checklist; but only people who are forced to use that checklist.
But it's common that if you work with governments that FIPS certification is a requriement.
So yea - great stuff!
It's a pain in the ass at times because it means things like Ed25519 and ECDSA not over NIST certified curves is not allowed...
Its been a while since I looked, but IIRC, there's some pretty major stuff missing like PKCS11 which means you can't do the CLI smartcard stuff you can do with OpenSSL.
I do seem to recall a few OpenSSL advisories in the last few years for which libressl was not vulnerable though.
OpenSSL is old and supports lots of platforms. Some people need to use OpenSSL because of the platform they're running on. I do hope the situation gets better, and over time we have seen competing TLS libraries replace OpenSSL in more and more places. It's not an easy problem to solve.
And changing that introduces a lot of risk.
Some platforms don't have a TLS library, but TLS is sometimes required. Some platforms have an outdated library and no reasonable update method. Some platforms have nasty bugs in their libraries. Some platforms have very inconsistent libraries depending on version. You might want to send extensions the platform library doesn't support (SNI used to be pretty hard to use), or to manage the acceptable CA roots (which I understand you dislike). You might want more control over ciphers, so as not to offer ciphers that are outdated. Having one buggy library you ship with your code is better than dealing with a different buggy platform library for each platform.