Doesn't matter if it's enabled or disabled by default. The point is, as OP pointed out, not everyone should be forced to protect a door to their data that they don't want there. Allow them to disable it.
Using phpMyAdmin securely does not require the command line. It can be installed locally and access the database through an SSH tunnel. MySQL workbench can create the tunnel itself. And if DH wants to host phpMyAdmin for everyone, then they should do it over HTTPS over their own domain as they do with the panel, webFTP (or whatever its called now), and pretty much every other web interface to your account that DH offers. phpMyAdmin is pretty much the only door to your account which DH enables by default which is not run over HTTPS by default.
Now combine that with inadequate warnings in the panel over database usernames and passwords (before I knew better, I thought I was supposed to use my shell account credentials!) and the incredibly weak password requirement of a minimum of six characters (even though DB passwords are generally saved in a file somewhere and not remembered), then it's extremely easy to start a distributed dictionary attack against the database behind every domain hosted at DH. With only six characters in the password, and a high likelihood that the password is the same as the user's password or the panel password, it's no wonder that people complain about compromised accounts so often.
Try it. Just search for 'hosted on dreamhost', and pick a random domain. The just add /dh_phpmyadmin/mysql. + the domain.com and viola! There's the door. This means that the Allowable Hosts whitelist in the panel gives a false sense of security because it's worthless if you use the default settings. Any warning about that? No. If you are like I was, then you would assume that the whitelist should help keep your database secure from outsiders. It doesn't. I just tried two random domains after searching for 'hosted on dreamhost' and both used default settings.
The only way to give yourself an ounce of protection, short of getting DH Support to begrudgingly disable it is to use an obscure subdomain for all of your database connections rather than the default of mysql and suchlike. A random string of 8 - 12 characters is a good start. Even if you do find someone at DH who can figure out how to disable it, the method they use is fragile. If you are moved to a new server, add a new domain, whatever, then your block is gone. I learnt this the hard way! After having it blocked and assuming I was safe, one day I checked by chance and there was no block! It turns out that it was because I had changed the database subdomain or something like that.
Do I even need to mention the fact that logging into phpMyAdmin is accomplished through HTTP Basic Authentication?
It's not simply an issue of, oh well, most DH users are simpletons so you just have to accept that everything will be insecure to maintain ease of access. No. It's not that. The problem is that the system set up by DH is inherently insecure. It's not about dumbing things down. It's not about ease of access. It's about design.
I predict that we'll just have to wait for a catastrophe. Just like the passwords fiasco. People, including me, pleaded for years to stop storing our passwords in a recoverable format. Many people claimed the same thing. Oh, we need it to provide better support, or too many people forget their passwords, blah, blah, blah.
Does DH store passwords in a recoverable format now? Well, probably not. Why? Because their design was flawed an their password database was breached.
It's a design problem. DH, your design is wrong!