Considering openssl processes a majority of the HTTPS traffic on the internet, I simply don't understand your question. Of course openssl is used in production. A lot. By everyone. All the time.
The API is not nice, the certificate processing code is not nice, the CLI is not nice, the documentation is often wildly outdated. It is not easy to use, and it is hard to use correctly. It will not hold your hand. It will not steer you away from danger. By all means, if you can, use Google Tink or libsodium.
There are two forks that tried to clean up the code by breaking compatibility - Google's BoringSSL and OpenBSD's LibreSSL. They are not very popular outside their organizations, exactly because they break compatibility.
The openssl code base has improved a lot since Heartbleed, it's not as bad as it used to be.
gpg is considered to be a dumpster fire comparable to Heartbleed-era openssl, so no, it's not better (look at the work of isis agora lovecruft).
If your question is about encrypting backup files for storage (or encrypting files to send to people over insecure channels), then gpg command line tool is better than the openssl tool.
The openssl CLI enc command should not be used, IMO, because its man page says:
For bulk encryption of data, whether using authenticated encryption
modes or other modes, cms(1) is recommended, as it provides a standard
data format and performs the needed key/iv/nonce management.
The openssl cli cms command is not the part of the openssl code that people use and trust, and I would not use it. Also, I would not use anything that tries to do openpgp or s/mime.
If you can use openssl's libcrypto API (for example with pyca/cryptography), I would prefer that over gpg. But if you're writing code instead of using a command line tool, I would use libsodium over libcrypto, to reduce chance of error.
But truthfully, I would prefer encpipe or age, because my own code was not reviewed by knowledgeable people.