Yes if you add that qualification your point is true but still not very compelling. The number of gratuitous HTTPS installations is low, I expect, given the hassle required to properly install it, so the ones that are there are probably there because secured communications were deemed necessary.
On the other hand, there is nothing inherent in HTTPS which makes it vulnerable to remote exploits such as these, anything in the stack could have such a vulnerability. Therefore I think it is misleading to argue that we're worse off with HTTPS--the same argument could be made for Apache, PHP, Linux, Windows, etc., as they've all contained vulnerabilities.
Lots of places use "gratuitous" HTTPS. This is particularly striking to me because I enabled HTTPS on my own site despite not needing it at all, and subsequently got caught up in this bug. Google.com could be another example. It's not strictly gratuitous because you can log in there, but in theory the search functionality could be partitioned off, and it did use plain HTTP for a very long time. For a more fitting example, DuckDuckGo uses HTTPS but doesn't, as far as I know, offer accounts or anything else that strictly needs security. They do it for the privacy of your searches, but if they were vulnerable to Heartbleed then they could have ended up exposing much more than they protected.
I don't think the argument is that you're worse off with HTTPS in general, only that in certain circumstances you were worse off in this particular case, and that should cause at least some consideration for the increased attack surface incurred in enabling HTTPS when you don't otherwise need it.
On the other hand, there is nothing inherent in HTTPS which makes it vulnerable to remote exploits such as these, anything in the stack could have such a vulnerability. Therefore I think it is misleading to argue that we're worse off with HTTPS--the same argument could be made for Apache, PHP, Linux, Windows, etc., as they've all contained vulnerabilities.