Conundrum with scaling out of bottleneck with hot standby, PgPool-II, etc.

Hi all, I have a general question on scaling PostgreSQL for unlimited
throughput, based on some experience.

TL;DR: My question is: given that the work-load on any secondary/standby
database server is almost the same as that of the master database
server, is there any point to bother with PgPool-II to route query
activity over the hot standby's, is it instead not better to just
increase the power of the master database system? Is there any trick
that can really get to massive scalability with the database?

Background: Let's say we're building a massive NSA citizens surveillance
system where we process every call and every email of every person on
earth to find dissidents and link this to their financial transactions
travel logs like airline bookings and Uber rides, to find some bogus
charges that FBI agents could use to put any dissident in prison as soon
as possible. And so we need a system that infinitely scales.

OK, I'm kidding (but keep thinking of adverse effects of our IT work)
but the point is a massive data processing system. We know that
parallelizing all work flows is the key to keep up. Processing the
speech and emails and messages and other transactions is mostly doable
by throwing hardware at it to parallelize the workflows.

There's always going to be one common bottleneck: that database.

In my experience of parallelizing workflow processes, I can hammer my
PostgreSQL database and all I can do to keep up with that is broadening
the IO pipeline and looking at the balance of CPU and IO to make sure
that it's balanced at near 100% and as I add more CPU bandwidth I add
more IO bandwidth and so on to keep those gigabytes flowing and the CPUs
churning. But it's much harder with the database than with the message
transformations (natural language understanding, data extraction, image
processing, etc.)

I have set up a hot standby database which I thought would just keep
track with the master, and which I could use to run queries while the
insert, update, and delete operations would all go against the master
db. What I discovered is that the stress on the hot standby systems is
significant just to keep up! The replaying of these logs takes
significant resources, so much that if I use a less powerful hardware
for the secondary, it tends to fall behind and ultimately bails out
because it cannot process the log stream.

So, if my secondary is so busy already with just keeping up to date with
the master db, and I cannot use a significantly smaller hardware, how
can I put a lot of extra query load on these secondary systems? My
argument is GENERAL not "show me your schema", etc. I am talking about
principles. I read it somewhere that you need to dimension these
secondaries / standby servers about the same capacity as the master
server. And that means that the standby servers are about as busy as the
master server. And that means that as you scale this up, the scaling is
actually quite inefficient. I have to copy all that data while the
receiving end of all that data is as busy receiving this data as the
master server is with processing the actual transactions.

Doesn't that mean that it's better to just scale up the master system as
much as possible while the standby servers are only a means of fault
tolerance but never actually improved performance? In other words there
is no real benefit of running read/query-only workloads on the
secondaries and routing updates to the primary, because the background
workload is replicated with every standby server and is not
significantly less than the workload on the master server.

And in other words, isn't there a way to replicate that is more
efficient? Or are there hard limits? Again, I'm talking principles.

For example, if I just make exact disk copies of the data tables on the
SCSI bus level (like RAID-1) for block write transactions while I
distribute the block read transactions over the RAID-1 spindles, again,
most of my disks are still occupied with the write transactions because
they all must write everything while I can distribute only the read
activity. I suppose I can use some tricks to avoid seek time by
scheduling reads to those disks that are currently writing to the same
cylinder (I know that's moot with SSDs but there is some locality issues
even for DDR RAM access, so the principle still holds). I suppose I
could tweak the mirrors, to track the master write with a slight delay
so as to allow some potential to re-organize blocks so as to write
contiguous blocks or blocks that go to the same track. But this type of
write scheduling is what OSs do out of a cache.

So, my question is: isn't there any trick that can really get to massive
scalability with the database? Should I even bother with PgPool-II to
route query activity over hot standbys?  I can buy two boxes of n CPUs
and disk volume to run as master and slave, or I can spend the same
money to buy a single system with twice the CPU cores and a twice as
wide IO path and disks. Why would I do anything other but to just
increase that master db server?

regards,
-Gunther