Actually while the compiler will not explicitly output instructions to access these 160 registers, compilers can and do take advantage of the fact that under the hood there are 160 registers instead of a dozen or so. They do this with "instruction scheduling" which carefully orders the instructions in such a way that at the end when the hardware is done with it they can be executed in parallel and thus need more than the dozen or so architectural registers.
So in a way "Compilers will allocate our local variables and function arguments to these registers" is correct.
Opposite actually - instruction scheduling is significantly more useful for in-order processors without renaming. Compilers take advantage of OoOE and register renaming by not caring too much about careful scheduling in favor of reducing register pressure.
For example, the compiler could order a sequence of load -> store copies as 4x load -> 4x store, or 4x (load -> store). They're equally fast on an OoOE CPU, so compilers might choose the latter so as to spill fewer registers elsewhere in the function.
It's true that the need for instruction scheduling is reduced in an OoO processor, but now you're comparing it to a processor that does not do OoO and hence needs to expose its entire register set as architectural registers. A compiler for an OoO processor still needs to be aware that under the hood there are 160 registers that can be used instead of 14 (at least if it wants to generate the most efficient code).
The article is oversimplified here to the point of being incorrect. The registers the compiler sees don't change (and there aren't 160 of them, I think there's a dozen or less), only the behind-the-scenes ones as the parent comment says.