Yeah, the ARM format of combining an 8-bit value with a 4-bit shift is more elegant. Deliberately limiting 8-bit and 16-bit functions to the first 2 registers helps if you want to implement functions like ARM parallel arithmetic (byte-wise or halfword-wise add, subtract, exchange, sum of absolute differences)

It also helps, with large registers, to split them into multiple smaller segments. Example: AH and AL are the upper and lower half of AX. 

Trouble is - the more you split up the registers, the more bits you end up using to reference them in your instruction set. So maybe you don't make EVERY register addressable in this manner.

32 bits => 32 registers. If the lowest 2 registers can be broken in 8-bit segments, that's 8 registers right there. Make lowest FOUR registers also available as 16-bit, and you have 8 more (16 total). Add 32-bit mode, and the lowest four registers account for 20 out of 32.

Final result: 32-bits => 16 registers (with 16-bit and 8-bit register support )

I... beg to differ.

This sort of hack creates all kinds of problems in the datapath, because you have to shift data all the time and a shifter adds latency in the critical datapath. The core runs slower...

Anyway, that's an excellent subject for a new principle :-)

This sounds like what Zilog did with the Z8000 and Z80000 processors.  These are awesome CPUs, and I hope to replicate one in an FPGA some day.  But, I agree with Yann -- it's just straight up awkward to deal with in hardware.  Zilog had the benefit of multi-cycle instruction execution rates; however, their processors never went faster than 10MHz last I recall.  (Z80 being an exception, but only because of die shrinks.)