If you were using .dev locally before then you almost certainly didn’t have TLS, since it’s usually local testing.
By making TLS mandatory you not only break local dev environments (that use that TLD which maybe have a legitimate domain outside of your network) you also make it so that it’s not even possible to run locally unless you do a lot of CA trickery to get a legit looking TLS cert.
My personal opinion was that this was a good move, as it forced developers to stop using .dev as soon as it was being used on the global internet- which avoided a lot of really awkward and annoying dual-home misconfigurations.
The fact that it broke anything for anyone is a strong argument that it never should have been created in the first place, alongside .home and .corp.
They were aware of the issue, buried it in the report and reneged on their promise to keep it internal-only. That was the mitigating argument for allowing it despite the known existing usage. Google acted in bad faith and I'd need to see concrete proof to convince me otherwise.
A lot of people had local domains (only entered in their hosts file or the router) on the dev TLD. Adding that domain to the hsts preload list not only broke their current setup, but also made it hard to bring it back to live - if you don't own the domain, the only option is to set up your own CA, with all included drawbacks.
I thought a host file entry overrides dns resolution— wouldn't a .dev domain that's already pointed at localhost not be affected by this? Or am I misunderstanding?