My pet theory: I'm pretty sure this is because when HTML5 became a thing, some major tech blog showed us what an HTML5 page would look like (simplified doctype, meta charset) and they included the viewport settings that disabled zoom.
Then pretty much everyone copied from these guides, and here we are. I remember I had used HTML5 skeleton templates for a while before I learned that the "maximum-scale=1, user-scalable=no" they came with is not a good idea.
Almost all major template for JS frameworks these days include that line. And there are tons of guides that specify adding that in.
I get why it's there, if you're building a PWA that is supposed to mimick a mobile app, you have to enable that to override some annoying mobile browser behaviors like zooming on an input.
The problem is that the above scenario is about the only time you would want to set the viewport in that way. Yet because the line gets included in boilerplates to make it easier to make PWA's, it ends up in a ton of stuff that definitely is not a PWA and should not have that.
Fun fact: the reason why browsers sometimes zoom in on an input is because the input's font size is too small, less than 16px, which is considered not accessible. So it's ironic that to counter that behaviour some people make the page even less accessible by disabling use zoom.
To be fair, I don't think the current implementation of auto-zoom, at least in mobile Firefox, actually makes things more accessible. The zoom it choose is ridiculous so you lose all context (and often can't even see the whole input element) and the screen constantly jumps around when filling out a form.
I assume it's something some "website builder" site like wix.com does. For instance, wix.com itself shows "user-scalable=no" in the viewport meta tag if your user-agent is from an iPhone.
> override some annoying mobile browser behaviors like zooming on an input.
Yep, I've seen some people disable zoom in their webpages specifically to prevent Safari from auto-zooming all over the place as the user moves from this to that input. It gets really annoying if you have anything but the simplest form. And what webpage doesn't have at least one form on it, even just the search box?
I fully agree with OP that disabling zoom is wrong. I also think it's wrong for browsers to mess with the zoom level without the user's instruction.
Almost every weird workaround we still have today in webdev was originally written to compensate for inconsistent browser implementation of some standard. In the past, IE was the one that always did something weird. Now it's Safari. Until browsers stop trying to pretend that they know better than both the developer and the user, somebody somewhere will keep writing these workarounds that then stick around in boilerplates and tutorials for years.
Safari only zooms if your input text is too small (less than 16px). The answer to defeating autozoom is to not make inputs that many people would need to zoom manually.
Developers are usually not the ones who are making decisions like this.
The manager doesn't want that annoying autozoom. The designer doesn't want to change the font size or page layout. There are also edge cases where something that was supposed to be 16px ends up being slightly smaller because of unit conversion and Safari zooms anyway. The developer, tired of this bullshit, googles a solution to satisfy everyone.
Fortunately, there's yet another workaround for developers stuck in this situation. Drop "maximum-scale=1", but keep "user-scalable=no" in the meta viewport tag. Safari will ignore the directive and allow the user to zoom freely, but this somehow disables zooming on inputs. Makes sense, huh?
One browser implementing a non-standard feature that doesn't even work consistently eventually hurts everyone, including the developer and the user. Just blaming the developer misses the larger problem.
Classic Hanlon's razor "never attribute to malice that which is adequately explained by ignorance"
Copy-pasting a template and just not being aware of accessibility and functionality requirements is most likely explanation here. Or devs being given 4k UHD monitors and never looking at their work on a small laptop.
In the late 90s and early 2000s every second bank round these parts decided to do their entire website in Flash. Not just some animations and videos, but I mean the actual entire content of the site was Flash, no HTML. As well as being basically unusable search engines wouldn't index it either so you couldn't find anything.
Also fun was being deep in one of those "rewrite the web browser in Flash" pages and realizing you made a mistake so you hit the back button and lose all of your progress as the whole page is unloaded. Sometimes I look at web frameworks and think that these developers are nostalgic for the days of Flash.
I can confirm that theory. I wrote my own HTML5 template for my blog when HTML5 was pretty fresh. I don't recall where I exactly got the boilerplate from. I thought it might have been html5boilerplate.com, but I just checked the v1.0 tag and that doesn't prevent zooming in. But I definitely took the tag from someone and just applied it without knowing what it does.
Then pretty much everyone copied from these guides, and here we are. I remember I had used HTML5 skeleton templates for a while before I learned that the "maximum-scale=1, user-scalable=no" they came with is not a good idea.