They use TPS as a unit because that's how large banks and other transaction oriented entities do their provisioning and capacity planning. That's their 'unit', not CPU cycles.
There are industry-standard benchmarks that measure TPS. See for example (or maybe not even for example; it may be effectively the only one in town) http://www.tpc.org/information/benchmarks.asp.
And of course, anybody considering buying such a machine will spend quite a bit on evaluating how it performs under their load, just like SPEC (https://www.spec.org/) says something, but not all.
Because they are not arguing with scientists but with "decision makers". So bullshit is more important than proven facts... Tanksfully, banks are moving slowly out of mainframes. You'll never find a new business going on a mainframe. Mainframes users are captive, not free.
You're thinking very much in terms of a PC architecture. Many components of the mainframe including a lot of the I/O hardware and some instructions in the assembly language itself are record oriented, and within reasonable limits operate on an entire record at once. It's not that big of a jump to go from entire records being atomic operations to at least speaking about entire transactions being the basic, atomic units of computation in the system.
Like a row in a table. I/O instructions in S/360 (as I recall) assembler would fetch an entire record in a single instruction / cycle (the I/O devices are radically different and would support this - it wasn't just syntactic sugar around reading a word or byte at a time). So the time to read in a record, perform some operations and write a record back out is actually much more predictable based on clock speed than it sounds like it would be to someone from a PC background.
