I read this to refer to the choice of execution model, not to exposing lower-level details of the hardware architecture. The CLR is primarily a stack machine, meaning opcodes operate on a stack. The other common option in VM design space is the register machine, where a (usually unlimited) set of virtual registers is manipulated instead. These registers are an abstraction provided by the VM (much like the stack in the alternative), so it is hardware-independent and has to be mapped to hardware registers for faster execution. Examples are the Lua VMs (both the reference implementation and LuaJIT), Dalvik, and the experimental (for other reasons) Python VM Falcon.
If my reading is correct, the remarks simply refers to the fact that it's a bit easier to generate stack opcodes from an AST than it is to generate register opcodes. On a stack VM, each (or at least most) AST nodes can generate opcodes like this:
child1.codegen()
...
childN.codegen()
emit(OPCODES_FOR_THIS_OPERATION)
for example, for addition:
lhs.codegen()
rhs.codegen()
emit(ADD)
In contrast, a register-based VM needs to carry around at least some state to manage which register all the temporary values are put in. And if it wants to avoid using far too many registers, some slightly non-trivial optimizations are needed (to re-use registers, or more generally perform register allocation).