Why would someone "double encrypt"?

It's not uncommon, but it may not be required. A lot of developers seem to forget that HTTPS traffic is already encrypted - just look at the number of questions about implementing client side encryption on this website - or feel that it can't be trusted due to well-publicised issues such as the Lenovo SSL MitM mess.

However, most people weren't affected by this, and there aren't any particularly viable attacks against TLSv1.2 around at the moment, so it doesn't really add much.

On the other hand, there are legitimate reasons for encrypting data before transmission in some cases. For example, if you're developing a storage application, you might want to encrypt using an app on the client side with a key known only to the user - this would mean that the server would not be able to decrypt the data at all, but it could still store it. Sending over HTTPS would mean that an attacker also shouldn't be able to grab the client-encrypted data, but even if they did, it wouldn't matter. This pattern is often used by cloud based password managers.

Essentially, it depends on what you're defending against - if you don't trust SSL/TLS, though, you probably can't trust the encryption code you're sending (in the web application case) either!

HTTPS only provides encryption while the message is in transit over the network/internet.

If the message is stored or processed by an intermediary (e.g. a message queue) at some point between the client and the server that finally processes it then it will not remain encrypted whilst it is in the intermediary.

Also, if the TLS/SSL is terminated at the service perimeters (e.g. on a load balancer) then it may not be encrypted on the internal network. This may be a problem where high security is required, for example in some regulated environments.

In both of these cases, message level encryption will ensure that the data is encrypted at all points in between the client and the final receiver.

As @honze said, this is called defense in depth and it is intended to ensure that even if a system is partially compromised (e.g. they manage to do a man-in-the-middle attack to compromise the SSL/TLS, or exploit a vulnerability in the message queue to get at the data at rest) the attacker cannot get at the protected data.

I'd like to share my experience on the title question. It's not really related to the complete question itself, but this answers the question "why would someone double-encrypt?"

In the past I worked for an organization that handles the communication between care providers (doctors, hospitals, etc.) and insuring organizations (mutualities). We kind of acted like a router.

The schema was roughly the following:

care provider 1 \                   / insuring organization 1
care provider 2 ---- router (us) ---- insuring organization 2
care provider 3 /                   \ insuring organization 3

We had the following protection:

1. End-to-end encryption: Care provider 1 needs to send patient info to insuring organization 1. This info is privacy-sensitive and therefore needs to be encrypted. At our level we have no right to know what data is being sent to the insuring organization.
2. Care-provider - router encryption: The care provider sends information as metadata for us to be able to handle it. This information needs to be encrypted. The contract stated that the messages still had to be encrypted even inside our network so that only one of our servers ever knows the metadata of the information being sent. Since we have several pipes (load balancers, firewall, etc.), encryption is required at this level as well.
3. HTTPS to avoid MITM attacks: Not only did our data need to be protected, but the HTTP metadata needed to be protected as well, therefore HTTPS.

I hope this sheds some light on why several layers of encryption can be required.