OpenSSL vs GPG for encrypting off-site backups?

Given the option between using GPG and OpenSSL for local encryption before pushing archives to an off-site backup location, what are the benefits and drawbacks of each solution?

Background: I currently manage a server infrastructure based on Ubuntu 14.04.1 with all current patches applied as they become available.

All of these systems are headless, automatically built using vetted preseeds and automation tools, and run in virtual machines via KVM on uniform Intel-based hardware.

We have a preference for Ruby, but a stronger preference for "doing things correctly". Because of both, we've chosen the "backup" gem as the means to create encrypted archives of data we want preserved, since it will create the same encrypted archives for a developer using Vagrant that it would in production, regardless of the mechanism by which it's transmitted.

All software and configuration is managed via Puppet, so neither decision will have any impact on "user experience" or convenience. Either option will create relevant scripts to manage, verify, or restore from any backups created.

Given that, does either encryption option offer any advantage against the other when used for this purpose?

I would pick GPG for file encryption, it's got decades of secure tested encryption, and is very easy to have multiple "recipients" (backup keys?) or signatures with it's public keys & even servers (if they would be useful).

With GPG, all the simple mistakes have been avoided/fixed, it picks a longer "random" key for the actual encryption and does a good number of "rounds" to make it very secure.

OpenSSL should be able to do all the same things, (it's been around since 1998, but if version numbers mean anything it reached version 1 in 2010) but it's very easy to make a mistake that could drastically lower the security. And from this post on security.stackexchange.com (from Jan 2013) and another by a 159K reputation user, the openssl enc command might leave something to be desired:

The encryption format used by OpenSSL is non-standard: it is "what OpenSSL does", and if all versions of OpenSSL tend to agree with each other, there is still no reference document which describes this format except OpenSSL source code. The header format is rather simple:

magic value (8 bytes): the bytes 53 61 6c 74 65 64 5f 5f salt value (8 bytes)

Hence a fixed 16-byte header, beginning with the ASCII encoding of the string "Salted__", followed by the salt itself. That's all ! No indication of the encryption algorithm; you are supposed to keep track of that yourself.

The process by which the password and salt are turned into the key and IV is not documented, but a look at the source code shows that it calls the OpenSSL-specific EVP_BytesToKey() function, which uses a custom key derivation function with some repeated hashing. This is a non-standard and not-well vetted construct (!) which relies on the MD5 hash function of dubious reputation (!!); that function can be changed on the command-line with the undocumented -md flag (!!!); the "iteration count" is set by the enc command to 1 and cannot be changed (!!!!). This means that the first 16 bytes of the key will be equal to MD5(password||salt), and that's it.

This is quite weak ! Anybody who knows how to write code on a PC can try to crack such a scheme and will be able to "try" several dozens of millions of potential passwords per second (hundreds of millions will be achievable with a GPU). If you use "openssl enc", make sure your password has very high entropy ! (i.e. higher than usually recommended; aim for 80 bits, at least). Or, preferably, don't use it at all; instead, go for something more robust (GnuPG, when doing symmetric encryption for a password, uses a stronger KDF with many iterations of the underlying hash function).