I can't speak for mike_d specifically, but there is a concern with having (potentially significant) modifications made to the codebase that aren't surfaced in the release notes. I imagine closed-source projects do this on a regular basis whether customers know (or care) or not.
The expectations for opensource projects are different though, particularly when it comes to system-level or near system-level components. So not being able to access the functionality is a great default but it doesn't address side effects of the changes or the desire to know about changes being made in our environments.
Until you decide to ship a completely on-prem Tailscale server, ACLs mean nothing. They can be modified by the same rogue employee that added an SSH server that bypasses local firewalls to our environment without telling anyone.
(We don't use Tailscale SSH, and are unlikely ever to; we have a separate source of authentication truth for SSH, and a separate certificate-based access control system.)
My hope was that with a little public prodding they would do better in the future. It is a product I want to like, maybe not for what you or I do, but lots of folks out there are slinging cat pictures where it will be a net benefit.
(1) a target server needs to run "tailscale up --ssh" to enable the SSH server
(2) your Tailscale ACLs have to permit it. Our default, if you've never set your ACLs (as is usually the case for personal users), is that you're allowed to SSH to your own untagged devices only.
For an org that's already using ACLs, you won't have any SSH rules defined and thus nobody in your org can enable the SSH server. (Or rather, they can enable it but nobody can connect to it.)
If your concern an org that's using the default "all packets are allowed" ACLs?