Unless you provide link who has suggested it and why, there's a huge field for guessing and speculation. I do not know the right answer to your question, and I believe that it may simply be historical.
Consider the following:
- The statement you cited is actually true; larger RAM set (and registers are organized as SRAM) required larger decoding circuits, thus more registers leads to more delays, and thus designers of RISC CPU should be lowering clock speed for reliable CPU operation;
- Look at this article, page 8. RISC having 32 registers against CISC's 16 registers was anyway the great breakthrough in computing. It may be that number of registers suffered the same myth of Bill Gates's 640KB RAM statement, and 32 registers was (and maybe still?) considered as enough;
- Discussion about having a lot of registers on the core is similar having a lot of cache. Significant research was made on cache sizes, and (to my knowledge) it was proven that larger cache sizes may hit performance negatively. So the same with registers; for general purpose math and data management software application 32 registers (32 integer plus 32 floating point) may be enough (my personal opinion);
- It would be logical to focus on increasing speed of main RAM access rather than increasing register set. You can increase number of registers to 1024, with significant increase in silicon cost, but you can easily increase external RAM from 256MB to 16GB with a fraction of that cost.
As a conclusion, the architecture of the CPU depends on the purpose it is designed for, the tasks it is going to perform and type of operations it is going to make; size of immediate RAM required (registers), size of all RAM required, etc. And of course the cost of CPU and its supporting logic.
but never mentions the fact that 32 registers is not enough
Enough or not enough register space is a subjective matter; some people consider 12 * 16-bit registers as enough when application can access 64KB of RAM. A lot of people code in high level language these days, thus do not care about register set at all, conversion into executable is handled by the compiler.
CPUs actually have at least 80 and sometimes more than 100 physical registers
Naming new registers within assembly language (in other words - giving code running direct access to those registers) requires standardization. Might be someone will dare upgrading 32 directly accessible register set into 64, 128 or 256 registers, and then try to promote new standard into the masses. Probably it is not economically viable at this time.
So why doesn't the reason for sticking to 32 architecture registers
Maybe for compatibility reasons? Imagine you release CPU supporting 512 directly addressable registers, and developers will start programming for it (using assembly or through compiler). Resulting low level code will not be easily portable to systems with 32 register set.
entails spending a lot of resources on register renaming
Renaming is not just about using extra registers available; this technique is more about parallelism and performance gained with it - including currently available code oriented (and already assembled) for 32 register set.