I believe the reason browsers are different from eg MS Office or applications using native widgets is that the toolkit sends higher-level events over RDP. For example, if you scroll, the toolkit sends a scrolling event telling the client to move one rectangle, and only sends the new content that the client does not have.
Browsers on the other hand do their rendering to a bitmap in order to get precise control over the output, so every time there is any update the entire rectangle needs to be re-sent. It is compressed, so non-image-heavy pages will be better, but it's still far less efficient.
You can see other evidence of this by looking at the fonts: if you have anti-aliasing enabled on your server, but disabled in your RDP client options, any application which still shows anti-aliased text is likely to have this problem since that implies it's doing its own rendering.
I only have a reference for this WRT Chrome: http://code.google.com/p/chromium/issues/detail?id=805#c1, but I believe it to be true of others; maybe somebody else can confirm/deny?
(Notably, Opera appears to honour the RDP client's anti-aliasing option and does indeed seem to be faster over RDP in my completely unscientific testing, so perhaps is not doing its own rendering to a backing bitmap. On the other hand it's still a lot slower than scrolling in Thunderbird, for example, so I'm not sure there.)