When the user hits "save password" on the client-side, the client needs to save the actual (plain text) password in order to replay it for future logins. A hashed password cannot be stored, otherwise that hashed password becomes the plain text password anyway (essentially destroying any benefit hashing would have here). The rules that apply to servers/services aren't the same as those for clients/saved logins.
Using reversible encryption is unavoidable, because they ultimately need plain text to send to the TeamViewer remote service. It is still marginally better than storing the actual plain text even if it is security through obscurity (using a hard-coded key in this case).
Storing it in the user's registry hive instead of a higher privilege allows the TeamViewer client to run in the user's context, instead of needing to run as administrator, have a broker, or similar.
One potential upgrade might be to use Windows' Data Protection API. It works essentially the same way as their current method, but Windows is responsible for protecting the encryption key (and has a broker than can house it at a higher privilege level).
But ultimately if you have a process running in the user's context and can manipulate the TeamViewer client, you can bypass the Data Protection API pretty trivially (e.g. injected DLL, UI hooks, other misc memory hooks, etc).
So my question would be: Describe the scenario where a bad actor has the ability to arbitrarily read data within a user's execution context, but not manipulate the TeamViewer Client also running in that same user's context? Because I got nothing.
My security advice here is simple: Don't save passwords to your local machine if you don't want them saved to your local machine. And don't leave backups of your saved passwords in insecure locations. I'm going to research if I can get a CVE assigned to that.