A root cause of the problem you've identified is that the tools are designed to offer first-class support for cartographic applications that pre-date the use of computers. Almost none of this has any relevance to modern geospatial analytics but it pervades the way the software works. Users that just want to build a modern analytic application are still forced to deal with this legacy baggage even though it provides no value to them and often makes their applications worse. The learning curve is unnecessarily steep.
Like you, I am of the opinion that a new set of GIS tools that focus solely on the needs of modern geospatial analysis users would be amazing.
Another gap is that cartographic tools have a deep assumption that geometry does not move. They don't provide support for correctly reasoning about spatiotemporal relationships, which are pretty important in modern geospatial applications.
Your last paragraph resonates strongly with me. I’ve taken my GIS skills and applied it to mobile robotics and performance often falls off a cliff when the moving elements aren’t treated very carefully.
OpenLayers and the rest do a great job these days, though. But a lot of the APIs are clearly intended for set and forget. “Why would you want to update this at 60hz?” I hear it asking me.
Good post. I haven't used Carto, Every Door, nor StreetComplete, but some of the consistency and non-ESRI-ness that OP is seeking seems to me to be present in Regrid fka Landgrid:
Like you, I am of the opinion that a new set of GIS tools that focus solely on the needs of modern geospatial analysis users would be amazing.
Another gap is that cartographic tools have a deep assumption that geometry does not move. They don't provide support for correctly reasoning about spatiotemporal relationships, which are pretty important in modern geospatial applications.