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.
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.
Yup, lots of weird edge cases. For that one, you could also represent it with a multipoly.
I had mine changed from a new zip getting added as the area's population grew (after it had been removed decades earlier).
Imagine a river that divides two zip codes, with river-front property on both sides. If that river has a bend in it (-∿-) that's greater than the width of the river+property, the polygon bounding one zip code would cut through the other, or the polygon is non-convex where it bends along the river.
(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.)