It is a hardware limitation. The fragment shader is part of the programmable pipeline, but the final color blend with the target buffer(s) isn't programmable in widely-available/commodity hardware at this point (it's configurable via blend states, but you can't write arbitrary code that replaces the GPUs built-in blend operations).
The reason the hardware isn't built for this probably has to do with the fact that GPU are massively parallel; they process many fragments at a time. Some of those fragments may ultimately interact with each other within the destination buffers, but due to the asynchronous nature of fragment processing it isn't possible to know how until after the fragment has been processed and final color has been emitted... which won't always happen deterministically.
Just because pixel A will be behind pixel B in the final frame does not mean that pixel A will always complete fragment processing and be written to the destination before B, especially across multiple frames of rendering. So the value read from the destination buffer during pixel B's processing will not always be pixel A's -- sometimes it will be the clear values.
So I suspect that disallowing direct destination buffer reads during the fragment stage has far more to do with stopping the shader programmer from shooting himself in the foot by getting potentially nondeterministic results from that read than from any actual technical limitation in making the blend stage fully-programmable. By keeping the read operations tightly controlled (the depth test, for example), the GPU ensures that the operations done with the read value make some kind of sense.
That said, there may also be a cost/benefit thing going on. Making that aspect of the GPU pipeline programmable would complicate the chip design somewhat, and the need/demand for destination buffer reads has been relatively low in comparison to other features.