PostgreSQL 9.3 will be coming out in beta soon and with that, some who want to experiment with both PostGIS and PostgreSQL 9.3 have asked if they can use PostGIS 2.0. The answer is NO. A lot of major changes happened in PostgreSQL 9.3 that required us to patch up upcoming PostGIS 2.1. These changes were not backported to 2.0 and I personally do not plan to back-port them unless lightning strikes me and I escape unscathed, a big wad of cash falls from the sky, or for some reason we can't make the 2.1 cut before 9.3 comes out. So if you are planning to experiment with PostgreSQL 9.3, PLEASE use PostGIS 2.1 development branch. I will try to make sure we release 2.1 before PostgreSQL 9.3 comes out even if I have to resort to hitting some people over the head with a rubber bat :).
Now some people might say "Isn't it cruel not to support PostGIS 2.0 for 9.3", and my answer is "it's crueler to". The reason is simple. We have limited bandwidth for testing permutations of things and the more permutations of things we support, the dirtier our code base becomes making it harder to maintain and also the less time we can devote to properly testing each permutation. I'd rather say we don't support something than to do a half-hearted job of supporting all.
On a slightly different, but also pragmatic note, package maintainers (except for windows maintainers :)) generally only carry one version of PostGIS per version of PostgreSQL, and I'd rather users getting from packages see our best foot than a two year old aging foot.
Note: that going from PostGIS 2.0 to 2.1 is a soft upgrade so you can install 2.1 on your existing PostgreSQL 9.2 without dump restore and then you should be able to pg_upgrade over to 9.3 if your database is too big to dump restore.
I think PostGIS became mature enough to become aligned to PostgreSQL release cycle. How about to move it to PG contrib or find another way to integrate it to the core PG?
Historical reasons of developing PostGIS separately become less and less attractive - you described reasons of that.
On the other hand - PostGIS is huge value to PostgreSQL. Why PG would insist to keep PostGIS separated?
We are still on a different release cycle mostly because our code base is fairly huge for a contrib module. Having to match release cycle with PostgreSQL would be very frustrating for us. We have enough fighting amongst ourselves when to release without having another group controlling us.
That said as dusty mentioned, the licensing is incompatible. But really the main reason is our module is too big to fit in PostgreSQL release cycle.
The other issue is a lot of GIS folks want newer features without having to upgrade PostgreSQL and are also tied to 3rd party GIS tools that only support X version etc. Being part of PostgreSQL would force us into a 1 version of PostGIS per version of PostgreSQL which I think would make everyone unhappier.
As much as I like to complain, I'd rather distros package more than one version of PostGIS per PostgreSQL release rather than we being forced into a one PostGIS version per PostgreSQL.