If you re-wound the universe to early 2001, and not only let the inventors of PostGIS see the future, but also let the PSC of PgSQL see the future, perhaps PostGIS would be a series of patches on PgSQL. But at a minimum, if we had started as patches to core, the first thing we would have run up against is:

core PgSQL areas don't support holes, but the GIS model really wants holes, can we change that?

And core PgSQL would have said: "no, of course not, areas have an existing well-understood semantic and we can't go making backwards incompatible changes like that".

As non-core developers, PostGIS was able to knock out monthly and 6-monthly releases for a number of years while PgSQL core plodded along with annual and longer releases. We were also able to add whatever features we wanted, whenever, since we had commit rights in our project, but gaining commit rights in PgSQL takes a Very Long Time.

By the time PostGIS was demonstrating enough external value that PgSQL core looked over and said to themselves "huh, that would have been nice to have in core as an extra feature", there was already so much code of such a different standard and style from PgSQL (not to mention under an incompatible license) that the idea of merging was not really possible.

Instead, PostGIS has become the canonical example of a Really Large Complex Extension that helps PgSQL remain modular and extensible. "How will this effect something like PostGIS" is a question often asked as core PgSQL evaluates some change. This is also a good thing, not perhaps quite as nice as PostGIS being part of core, but good enough.

There's other reasons, like the long list of dependencies PgSQL core would have hated to see, the generally lower code consistency and API cleanliness which they would have despaired of improving, and on and on. Even at conception, PostGIS was too big a hairball for PgSQL to swallow in one bite.