This seems like a textbook case of Hanlon's Razor (https://en.wikipedia.org/wiki/Hanlon's_razor, "Never attribute to malice that which is adequately explained by stupidity"). They wanted some way for their website to interact with the user's local installation of their software, and somehow arrived at the idea of running a web server on localhost and accessing it from their website, without thinking through the security implications at all. Even their responses in this bug show that they still don't really understand the implications.
Less broken software tends to solve this same problem using a browser extension with a whitelisted ___domain for access, but that has the disadvantage of requiring a browser extension for each browser, and doesn't fully protect against hostile networks. Including the "https://" in the whitelist would provide somewhat more security, especially with HSTS, a pinned certificate, and a carefully-audited single-purpose ___domain.
But an even better design would eliminate the entire concept of connecting back from the vendor website to the client software. Sometimes the right answer to "how do I" is "don't".
Some programmer on a project sees a lot of code that's calling out to various Windows functions and thinks, "You know, it'd be a clean refactor if I just merge all these into a single abstract route on the server that could call any Windows function."
