These map apps with cached tiles (whether raster or vector, doesn't matter) gain speed precisely because they limit what the user can choose and then cache that. The normal GIS apps cannot do that, but conversely, their users are complaining that Google Maps is much faster...
At least assuming a halfway decent implementation (it shouldn't take real long to process the few hundred items that would be present in the viewport).
What Mapbox can do, is to _remove_ data that are not in stylesheet - but as I understand it, that is being done server side (https://www.mapbox.com/blog/style-optimized-vector-tiles/). So in theory you could put more data into generated tiles, users could create their customized stylesheet (would have to be found out how, the server needs to have it accessible, it does processing based on it) and it could work - for a few of them. If everyone would do it, you are back to square one. This is usually usable for a defined roles (what group can see what in your data), not for picking and choosing every possible object at arbitrary scale.
The thing is, you usually cannot put all the data in the tiles and just serve them - most users won't use them anyway, so you would just waste bandwidth. That one guy who wants something special usually wants other object than that second guy, who wants also something special.
It would seem to me that, as pipes get thicker and bandwidth keeps growing, we will inevitably hit the point where it's easier to just server raw data and let the client render it soon enough.
It has a rather complex UI though and the availability of POIs will depend on the quality of OpenStreetMap in the area you are interested in.