Thanks for you suggestion. This feature has been requested before a few times.
Unfortunately, it's not as easy to implement as it may seem. The reason for this is that it's computationally expensive to determine what element is under the mouse cursor (it takes about 5 milliseconds). If we multiply that cost for each time the mouse changes position in one second (which can be up to 50 times depending on how fast the user is moving the mouse) we get:
5ms x 50 = 250ms
That is, up to 25% of CPU time is going to be consumed while the user is moving the mouse. This is way beyond an acceptable CPU usage for a background software tool that's always running. Therefore, the trivial mechanism of checking the hovered element every time the mouse moves is not an acceptable implementation. A smarter mechanism would be needed that somehow achieves an acceptable CPU usage.
Also, the usefulness of the feature is quite narrow. The tabs in the tabstrip are the one element for which it seems useful to have a hover trigger. The other elements of the browser interface seem much less useful as hover triggers, such as the webpage area or the title bar or the omnibox.
So, even though the feature can indeed be implemented (with some limitations), what keeps us from doing so is the fact that the cost-benefit relationship doesn't seem favorable.