From that reddit thread:

Sharing some perspective on this (I was involved in the fix).

Basically what started happening at some point was that Maps had built in a “timeout” for the fetch of Saved lists. When the lists weren’t able to be downloaded/fetched in under X seconds, the system stopped trying, assuming that lists in general would always load in under X seconds.

For users with huge lists, and for some users with very slow connections, it would timeout and not show anything. The way to notice it was typically when sharing the list, because the receiving user would fall into that timeout trap. The owner of the list usually didn’t notice immediately because the places were cached on their devices.

It’s still being worked on, and being rolled out slowly.. Some changes will come though, not sure how it’ll be announced.

My perspective as an ex-Google SWE:

It is someone's quarterly performance review and OKR to improve SLO. One such SLO is average load time. If you set such metrics as a goal, and financially reward people to do it, it's easy to meet the goal: arbitrary prune out the long tail, especially if the distribution of saved locations per user follows an Pareto/power law distribution.

They've since rolled back that experiment of payload sized limit, and instead used this number based limit. I guess it makes more a cleaner explainaton and internal documentation from a product sense this way as opposed to an arbitrary engineering limit.

The issue is still apathy and laziness from the engineers... they can have this per-request limits, but cache previously loaded pinnned locations, then incrementally append more to the list on subsequent requests. Instead, they attempt to reload the source of truth from the server everytime. There is a specific behavior where I see this is the case: they will load 3,000, you add another location which is now 3,001 locally, but after a few minutes they reconcile with the server and your local machine is back to 3,000. This is especially ironically considering the Google interview's emphasis on Dynamic Programming and building up a larger solution from previous solutions...

On Desktop, you can still load all your locations. There is some weird and intuitive behavior here how they reconcile edits to existing pin. The caveat on Desktop is that they will entire to render entire regions when there is too much (somewhere in the vicinity above 3,000 but below 8,000). I've noticed in recent weeks they've rolled out a quadtree implementation where in a given rectangular region, they'd limit and cap how much saved locations they attempt to render, versus before where it would be seemingly depth-first until they reach the 3,000 limit.

That change is hilarious. So many potentially goofy reasons for it happening but my best take is google deciding not to host any data it can’t mine or use. The privacy policy on location history was quite good and effectively granted users privacy.

Privacy policies don't help your users against subpoenas.

If they cared about privacy they could have easily hosted the data encrypted with a key only known to the user rendering subpoenas useless for that service.

Or they could just not upload it. No one trusts E2EE systems; you can see Apple tries it and everyone just accuses them of putting secret backdoors in.