It is mostly a license issue. These developments end up patching the code quite heavily, so if you were to deal with MySQL, you'd either have to open-source your code or be at the mercy of MySQL's corporate owner for the life of your business. Some offers for MySQL get around that by implementing their work as a storage engine, but that doesn't offer all the flexibility that they need, and they invariably end up patching the MySQL core as well.
In our shop we selected repmgr and pgbouncer instead of pgpool. repmgr has some nice tooling to setup and maintain the cluster of replicated database servers. In our case 1 master and 2 slaves (one failover and one live read performance test that can become the failover of the new master). pgpool has issues with changes in the configuration, in most cases you have to restart the service and therefor you have some downtime. This is a problem when you need 24x7x365 availability.
repmgrd (the deamon) helps to select the new master after a failover, you really don't want a split brain situation. We have one virtual ip-address for the master database, the database that is master at that moment. When another server becomes master, this is the only server using this address. Every database server also has it's own ip-address for read only queries.
repmgr is maintained by the same guys that created streaming replication in the first place, so they know what they talk about. Version 2.0 is about to be released.
Prepare for the worst situation, do some serious testing by pulling some power and network plugs! When something goes wrong, many other things already went wrong and will bite you in the back when you can't afford it.
Replication is one thing, a working failover after some serious problems, is another thing.
Best Answer
Oracle's Data Guard replication is similar to PostgreSQL's "Hot/Warm Standby Using PITR", which is built-in to the database as of PostgreSQL 9.0. Version 9.1 adds synchronous replication too. One advantage that PostgreSQL has over Oracle here is that Sync Rep can be controlled on a per-transaction basis. You can have a fully synchronous "Important!" Transaction followed by an asynchronous "OK to lose" one in Postgres.
Oracle's RAC is similar to what PostgreSQL is labelling "Shared Disk Failover" in that grid. The main difference is that RAC is fully integrated into Oracle's product, while "Shared Disk Failover" just describes a method of doing something. You have to assemble the necessary clusterware software around that for PostgreSQL, and there are a variety of advanced things RAC does you'll be hard pressed to duplicate in PostgreSQL. I regularly hear that most of those things are so complicated to setup that few Oracle installations get them right either--just because RAC is built-in doesn't mean it sets itself up automatically.
The main thing you can do in Oracle that is very hard to duplicate as well in PostgreSQL is multi-master replication. It's possible to do multi-master in PostgreSQL, but only with add-on software like Bucardo. And all such programs still have more restrictions on what you can do with them than the Multi-Master Oracle installations provide.