I am the original author and the "it's not a public/published API" is an idiotic defense.
The public/private API defense is very valid.
If someone takes something, uses it for a purpose other than originally intended, and then flaws are found in the new use, those flaws do not necessarily impact the original purpose. Using a razor blade as floss to clean your teeth is unsafe, but that is not a flaw in the design of razor blades.
Another comparison: the iPhone 2G unofficial SDK. Should Apple be held responsible for flaws in the way people used that SDK before they finally released an official SDK?
In the case of this API, Tesla's use of it is for their iPhone and Android Apps to control their own cars, not for third party websites, apps or services. At some point, Tesla may release an API/SDK for third party use, and if at such time this authentication mechanism was still used that would be a problem.
The stated flaws:
* It cannot safely operate over any channel but a trusted SSL connection (minor)
* It requires the sharing of the user’s password with third-parties (major)
* No mechanism exists for cataloging applications with active tokens (significant)
* No mechanism exists for revoking the access of a compromised application (major)
* The automated expiration of tokens in 3 months encourages applications to improperly store your email and password (significant)
Are primarily related to third-party Apps, not Tesla's own Apps. As Tesla did not intend for this API to be publicly used by third parties, it is harsh to castigate them for this. When used for its intended purpose, I don't see the issue.
Now, there might be some flaws with the Tesla approach. Most notably that a SSL MITM attack can steal credentials (as with many such protocols), but in Tesla's case it appears that changing the password does not invalidate the already issued tokens.
But, none of the above five stated flaws affect users using Tesla's product in the authorized and supported ways.