I once built an interactive map for some areas in Switzerland with postcodes rendered on it. I had to use a lot of tricks to keep it down to a few hundred KB for just about 5% of Switzerland's area. If I tried to add more areas, I'd have to abandon the approach of rendering polygons directly with Leaflet and move to static, pre-rendered images. Now, if you add 10 or 100 times more points, you would barely be able to render it fast enough on the CPU anymore.
So, nice idea, but the polygons become hard to work with then.
Here is an example using Mapbox GL - https://demos.mapbox.com/boundaries-explorer/?country=US&lay...
Quite something to see this in a browser on my phone, rendered that easily. I can clearly remember how hard this was back then.
I think the one I enjoyed the most was a zipcode with 38 separate geographical areas, and the other example was a street where one half was one zip code, and the other was a different one, but half way down the street they swapped sides. Representing that with non-overlapping polygons was impossible. So we just let them overlap and shrugged.
Yup, lots of weird edge cases. For that one, you could also represent it with a multipoly.
But in general, having more points really doesn't help with processing geo data. As you said yourself, you had to decimate the polygons. It's always compute vs. precision.
(My standard example used to be the World Trade Center, which had two - not one for each tower, but one for the state government offices and one for everything else.)
I had mine changed from a new zip getting added as the area's population grew (after it had been removed decades earlier).
I suppose though, as long as you let the polygons map has uncontained areas, where no routes currently exist, it's a doable task to draw polygons around the limits of every route network, as long as you don't mind that they may have lots of weird ragged edges.