If you have, say, 'add r1, r2, r3; add r2, r2, 1' and want to do the latter instruction in-register-file, you can't reorder them (e.g. if r2 is known before r3) as after having ran the second instruction the first ones r2 operand would be nowhere to be found. You'd need to track whether there's any unfinished usages of each register (or maybe the simpler option of just tracking if it has been any operand), which isn't traditionally required.
Perhaps a bigger issue is that, if you have a speculative decision (incl. all loads & stores) between having written a register and the clobbering update, you can't do it in-register too, as that'd make it impossible to rollback.
Thanks! This and some of the other comments have been helpful in understanding how these things work in more detail. So conceptually register names should be seen as result names - the result of a load or an operation gets called r2 for example. The ISA only provides so many result names, but the CPU may have any number of physical registers to store results. It's a nice model, and modifying a result in-register would really mess things up. It would destroy a previous result which would require a very different (more complex) approach to scheduling and clean up.
Perhaps a bigger issue is that, if you have a speculative decision (incl. all loads & stores) between having written a register and the clobbering update, you can't do it in-register too, as that'd make it impossible to rollback.