The increased vote count helps, but there’s still other considerations.
When Google first rolled out their version of the Nest API, they required an annual security audit and implied it was in the 5-6 figure range depending on implementation which would be between hard and impossible to justify.
They are a bit more vague now simply indicating that an annual security audit is required and that the annual cost is on a case-by-case basis.
Unfortunately, it seems like it might be a chicken-and-egg thing were you can’t do the commercial review until you have an implementation in place… but it’s hard to justify building an implementation if you aren’t sure the commercial review would yield a viable result!
Nest w/ Other Hubs
Some companies like Hubitat completely walked back their Nest beta releases and relied on their communities for ‘self install’ methods. Home Assistant also takes a similar approach with a self install. It looks like Hubitat now links you to their Matter integration when trying to connect a Nest thermostat now though.
Matter
The other thing that’s changed between the original sunset of the Works With Nest legacy API and release of the new Google Nest API is the growth of the Matter standard.
Unfortunately, this is a local API so it wouldn’t work with a cloud-to-cloud integration like this. But perhaps if we ever created a ‘bridge’ that could run locally that could pull in Matter devices too.
Workaround
In the meantime, connecting a hub that supports Nest thermostats (eg. through Matter or a self-install method) which would allow you to authorize your Nest thermostat to SharpTools would be a workaround.
Unfortunately, SmartThings implemented a really strict Nest integration where they don’t expose the Nest thermostats via the SmartThings API. I suspect this was a compromise as they had run into several other snags during their initial Nest integration like having to reduce their device history and other things to get the Nest integration.