One of the nice things about HTTP(S) is it has rerdirect semantics (to shed load) and requests are easy to send through a load balancer. 30k requests per second for static web data is well within the capability of a modestly scaled cloud or random assortment of machines in someone's data-center.
Also remember old networks that fed mainframe apps used to be pretty slow. I'm more familiar with old school travel agent tech. it was not uncommon to have offices of 5-15 travel agents all sharing a single 56 kilobit data line. So much of the coolness of mainframes was being able to aggregate hundreds or thousands or tens of thousands of remote terminals in the time when a 1200 baud modem was considered "fast."
And when they say "transactions" they're not talking about web requests, they're talking about multi-phase commit over multiple sub transactions, all of which have to be unrollable if any of them fails.
When I was at IBM/AIX division in the early 90s, we were excited we could get 30 tpmC out of a $15k RS/6000. The AS/400 team down the hall would snicker at us and invite us to watch their $30k entry level machines doing something closer to 500 transactions per second.
But the thing is... they were using a much simpler data representation scheme that made it MUCH easier for data inconsistencies to creep into the process.
So... modern PCs are more architecturally similar to old mainframes than old 8/16 bit micros. And they're certainly faster. But those old systems had plenty of tricks up their metaphorical sleeves.
This is a very odd number. 30.000 sounds super low for most things today, it might depend on which transaction we are talking here.
But due to this very strange and not really helpful statement I wonder. Are we looking at another AI generated and insufficiently redacted article ?