As mentioned above, in another comment, a big tradeoff is potentially maintenance and operations work. It may not be a hard thing to maintain, but it's another dependency that's not core to Postgres.

I've done a lot of ops work in my dev career, and I'm always reluctant to add another dependency (JS, btw, makes me crazy with how little is included in the standard library, and NPM is required for everything). So, I might be tempted to follow the advice in the article, and avoid using PostGIS for the simple use cases provided in the article.

For reference, I've also helped with non-devs work on python code for GIS systems for daily delivery systems. So I would most definitely be tempted to try to utilize PostGIS if I was in the GIS world dealing with map updates, and daily starts and stops.

Side note. Having been a programmer for several decades, and professionally for a decade at the time, I had truly forgotten how bad novice programmers are. Nested loops on long running functions all over the place (calculating optimal routes is not cheap computationally). It felt good to get some perspective at the time by helping the GIS department with their code.

Back in the day, a GIS pro gave a talk at OSCON on how far he could push Open Source software to do mapping for free.

One of the best talks I've ever seen, although if you do that much work yourself, you might as well form a company.

I consulted for the Canadian JPL, so I had tons of satellite data, but it was mostly ice, tundra and forest regions. Not much urban data, alas. :)

Although you could take your notebook down to the Ministry of Works and they would plug in a cable and give you all their street data at the time for free. I actually did that once.