I don't think there is a "limitation" to Solidity being able to implement low level features/accesses, such as the types of things Serpent can do. However, the two languages may have different priorities. Serpent is likely focused on lower level features compared to the flagship high-level language Solidity.
Ethereum high-level languages in order by closeness you can get to directly access the EVM:
- LLL (lowest level, basically 1 step above EVM byte code)
- Serpent (super-set of LLL)
- Solidity (compiles down directly to EVM byte code)
Serpent has direct access to EVM opcodes (it is a superset of the LLL high-level language), but it also has a bunch of high-level features as well. The downside to Serpent is that the compiler is more complex and so theoretically might contain more bugs.
It can be argued that Solidity is more prone to stack-depth related problems:
Vitalik Buterin wrote this Reddit comment:
Solidity compiles all variables into values on the stack,
and DUPN methods in Ethereum only let you fetch the 2-16th value from
the stack at any one time. The actual stack depth is 1024. Serpent
variables compile into memory accesses, so you don't have that problem
in serpent; to get around it in solidity I'd recommend you try to pack
things into structs more.
Being the flagship language, Solidity has been focused on different priorities than Serpent. Solidity has been less focused on adding low level features in favor of higher level features, but I don't think it is impossible to add more low level features to Solidity. In fact, there is a story on the Solidity development roadmap to add inline ASM into Solidity, which would allow lower level access to the EVM.