I run a modest fleet of mostly-offline data collection devices that rely on GPS; we pay a lot of attention to how long it takes before they can sync. With a good sky view, the GPS chip often has a 3D position lock before Linux has finished booting.
It's not really a limitation of GPS, it's about using the external service to let you minimize the time your GPS receiver is active. You can get a great fix without AGPS, but you can't both keep the GPS off 99.9% of the time _and_ get a fast, great position fix.
Yes, after waiting minutes with good line of sight for almanac and ephemerides to download from the satellites. Anything that gets a fix faster is already "assisted", usually either by fresh data downloaded online or not-yet-fully-out-of-date data stored locally.
I've been working on a phone that didn't have well-integrated AGNSS and used MLS for WiFi and cellular-based location when it didn't have GNSS fix. I'm perfectly aware that what you're saying is technically true, but try to explain that to the users :P
From the user perspective, it's not going to be a good experience if you rely on cold GNSS only on a mobile device (unless the user is already well aware of what to expect and how to behave).
Fair enough, I suppose. I think in the context of smartphones, continuously operating the GPS chip is simply not an option, but in other types of devices that isn't as big of a problem.
What you're seeing is the effect of AGPS and the interaction with the phone's aggressive power management. https://en.m.wikipedia.org/wiki/Assisted_GNSS
It's not really a limitation of GPS, it's about using the external service to let you minimize the time your GPS receiver is active. You can get a great fix without AGPS, but you can't both keep the GPS off 99.9% of the time _and_ get a fast, great position fix.