Yes, that is a proble. But why does is happen?
Originally with Linux, Windows XP, and MacOS 9 application windows were rendered directly on the screen. This allowed easy 2D acceleration with the hardware of the day.
However modern systems use 'compositing'; Starting with Mac OS 10. That is the application windows are rendered off the screen in their own private area. Then the image of the window is taken with other rendered images and put together to form one big image for your desktop.
That is why it's called 'compositing' because it's taking little graphics and compositing them together into one big one.
This allows fancy special effects. Like 'Compiz' which takes the rendered window images and uses them as textures on a 3D object. Then that object can be twisted and deformed or shaped like any 3D object.
The reason why moving windows around is fast and resizing windows is slow is because when you move a window around in a composited desktop you don't have to re-render it. It's just you moving a texture around on a screen. No need to make a new texture, you just use the one you already have. However when you re-size a image you have to re-render the entire window... As you resize all the elements in the window need to re-arrange themselves. You have to make a new texture. When you are trying to do a smooth resize that may require dozens and dozens of rendered textures to try to do a smooth transition.
The reason it was really slow in this video was because its probably just a very low-end machine. Probably a netbook or something like that.
This is a problem on all composited desktops. Windows Vista/Windows 7 Areo, Mac OS Aqua, Linux Compiz, or Linux Gnome 3.0's gnome-shell. If you watch carefully when people do demos to show off their fancy 3D desktops they usually avoid resizing windows.
To make this fast it just requires better drivers.
Currently with most Linux stuff, for example, the 2D and 3D drivers are separate drivers. So when you need to render a window to a 3D desktop you first do a 2D render, then you take that image and render that image to a texture, then you render that texture to a 3D primitive. If the 2D and 3D was rendered with the same unified driver then you can cut out the middle man and use the 2D rendered texture directly in 3D cutting down on a lot of cpu usage and texture copying.
Stuff like that is what it'll take, but it can only mask the issue with quicker and quicker render times so that you just stop noticing the problem. It won't make the fundamental part go away.
By The Way:
Touch screens kick-ass. Totally love them. I wish all my laptops had touch screens.
With multitouch it should be possible to do actually good onscreen keyboards....