Back in 2011, the HBO Go application on iOS contained a similar certificate for 127.0.0.1; I believe in that case a certificate for the bare IP address or just "localhost" that they got from Verisign. It was noticed by jan0 from the iOS jailbreak community, who had written isslfix, with the goal of hacking in a fix to a bug found in Apple's SSL certificate verification. He had some logging and noticed this extremely weird certificate get checked.
https://github.com/jan0/isslfix
The file was embedded in the binary as a base64-encoded PKCS12, but was encrypted with a password. They thought they were clever and used a format string to cobble together multiple parts that they then ran through a base64 decide to get the password. When jan0 told me about it, I spent a couple hours reversing the logic until I worked out the password... only for jan0 to tell me after that he had simply used one of my tools to hook the decryption itself and it only took him a few minutes ;P.
(I scavenged my stuff and found a copy!) The password to this file--which is the one directly taken from the binary, and so this is the original password (!!)--is "AmsterdamIsC0ld". (I have given talks about "the fallacy of trying to secure content inside of a binary you give to your attacker", and this password with that 0 for the O always manages to get some laughs ;P.)
http://test.saurik.com/hackernews/localhost.der
As for why this absolutely should be frowned upon: this doesn't provide any actual security... if everyone has the private key then anyone on your computer can man in the middle attack this connection. This is no better than just using HTTP to connect to this local service: the only reason you are even using SSL here is to bypass a security check in the browser (that an SSL website can't access a non-SSL website).
And if you want to argue "it is a local computer, why is a man in the middle attack relevant", you need only see the work people in jailbreak communities for random devices do to escalate privileges through various otherwise protected and sandboxed applications... made all the more obvious in your own description as it is the security of this website that is being undermined now (as maybe returning weird stuff from its API will mess with the user's site account or network settings or just break the website and give you arbitrary JavaScript execution).
I mean, in this case, you can't even guarantee the connect is to localhost! You start by swapping out the DNS to redirect drmlocal.cisco.com to some other IP address, and now you can get that website running on one computer--which you might not even have physical access to!--to talk to your forged copy, and trick the user into interacting with it, possibly letting you steal authorization keys or doing any of the other aforementioned described "bad stuff".
I will argue a local CA is absolutely "better", even if the optics are worse: you can generate the key for the CA, use that key to generate a key for just the one host, destroy the private key for the CA, and then install the public key. You now have a CA installed that can effectively only ever be used for the one host.
Of course, that causes a problem that you are training users to install CAs. If you dislike that, you can either use a proprietary browser or lobby browsers and OS developers to provide support for installing a CA limited to a hostname pattern: the fact that these do not exist is the real problem here and is downright criminal, as we know people want to do stuff like this, and it isn't even a ludicrous concept.