Note that the part of this answer below the horizontal line was written in 2012, back when the question was asked. At the time, only a small part of the web used HTTPS. Since then, most of the web has switched to HTTPS, so the short answer is ”they are”. This answer is still relevant insofar as it explains what HTTPS does and does not secure, in the context of application downloads.
Because HTTPS is not very well suited to securing downloads of large public files. For this use case, it's slow and not that useful. There are reasons for not using HTTPS well beyond incompetence or unawareness.
HTTPS doesn't fully solve the problem. This If you're getting your application straight from the vendor's website, HTTPS does ensure the authenticity of the application. But if you're getting your application from a third party (e.g. mirrors of free software), HTTPS only protects the connection with the third party. A package signature scheme works better: it can protect the whole chain from the vendor. Application distribution requires end-to-end protection and HTTPS doesn't provide that.
HTTPS uses more bandwidth. The overhead per download is minimal if you don't take caching into account. This is the spherical cow of “HTTPS doesn't cost more”: if you use SSL, you can't cache data except at the SSL endpoints. Application downloads are cachable in the extreme: they're large files that many people download.
HTTPS is overkill. The confidentiality of an application download is rarely an issue, all we need is authenticity. Sadly, HTTPS doesn't provide authenticity without also providing confidentiality. Authenticity is compatible with caching, but confidentiality isn't.
HTTPS requires more resources on the server. Google mail got it down to a 1% overhead and a 2% bandwidth overhead, but this is for a very different use case. The Gmail frontend servers do more than mindlessly serve files; a file server doesn't need a powerful CPU in the first place (it's very strongly IO-bound), so the overhead is likely to be significantly larger. The same goes for memory overhead: a file server needs very little memory per session in the first place, almost all of its memory is a disk cache. Getting the resource usage down requires a serious amount of work.
HTTPS wouldn't help many people. The security-conscious will check the hash provided by the vendor (that should be over HTTPS). The non-security-conscious will blithely click through the “this connection is insecure” message (there are so many badly configured servers out there that many users are trained to ignore HTTPS errors). And that's not to mention dodgy CAs who grant certificates that they shouldn't.
If you want to make sure that you're getting the genuine application, check its signature, or check its hash against a reference value that you obtain with a signature (for example over HTTPS).
Good vendors make this automatic. For example, Ubuntu provides GPG signatures of its installation media. It also provides the hashes over HTTPS (sadly not linked from anywhere near the download page as far as I can see). After that, the software installation tool automatically checks that packages come with a valid signature. See How to use https with apt-get?
Note: if you're getting the application directly from the vendor (as opposed to via some package repository or application marketplace), then HTTPS does provide protection. So if you're a vendor providing your application directly for download on your website, do protect it with HTTPS!
The data can't be read by a middle-man while in transitdoes not apply in application download scenario. If I know you're visiting mozilla's website and you're downloading a large amount of data, it is almost certain without even looking at your data stream that you must be downloading the latest version of Firefox, and I can just go to Mozilla instead of having to decrypt your data stream. So serving application downloads over HTTPS only really protects against MITM.