What the video is talking about is called gamma correction and it's a very familiar topic for graphics programmers. The first 30 minutes of John Hable's talk on Uncharted 2 rendering is my favorite introduction to "why graphics programmers should care about gamma", as well as being a good introduction to HDR rendering. If you don't want to watch the talk (though I highly recommend it), The Importance of Being Linear is also a good article, and Charles Poynton has a Gamma FAQ that goes into more technical detail and explains the terminology used.
By the way, square/squareroot is only an approximation; the sRGB gamma curve is what's most commonly used in practice (see the formulas there mentioning $C_\text{srgb}$ and $C_\text{linear}$). See also this related question about gamma and color spaces. It's a bit more complicated of a topic than the video makes it sound. :)
To answer your specific questions:
Yes, most image data is stored in gamma format, so the pixel values do not represent linear luminance. I wouldn't describe it as "incorrect", since gamma encoding has the useful property of putting more values in the darks, which is better for perceptual precision (as mentioned in the video). Gamma encoding is absolutely necessary to make good-looking images with only 8 bits per RGB component; if you stored linear values you would need more like 12 bits per component to get enough precision in the darks.
To be more physically correct, when blurring an image, one should convert it to linear luminance, then do the blur (Gaussian or otherwise), then convert it back to the original color space.
The monitor accepts image data in gamma format. So the pixel values do not represent linear luminance, and the output brightness is not linearly proportional to the pixel values.
If it's a good-quality, calibrated monitor, then it accepts data in a specific color space such as sRGB or Adobe RGB and reproduces the colors accurately based on the definition of that color space. If it's a crap uncalibrated monitor, then who knows what you'll get, but it'll be something kinda like sRGB.
GPUs can be configured to do various things here. Modern GPUs have hardware support to automatically convert values between gamma and linear when sampling a texture, or storing a value out to the framebuffer, but the programmer has to explicitly enable that using an API such as Direct3D or OpenGL.
Computer graphics people certainly do know about this topic, and it's critical to get it right when building a realistic renderer for film, AAA games, and so on. However, a lot of more "everyday" apps like web browsers and image editors (even Photoshop, as the video mentions) don't really handle gamma correctly.
It's not an issue of processing power; maybe that was a problem 20 years ago, but today even mobile phones have ample processing power to convert images between gamma and linear. The reason why web browsers and image editors still don't get this right is some combination of (a) ignorance, (b) not believing that gamma is important enough to be worth getting right, and (c) simply being stuck with bad behavior because it's been that way for a long time and users have come to expect it, so they freak out if something changes.
As mentioned, we have to think a lot about gamma when building a renderer. Most computations (e.g. lighting) should be done in linear space, but the input textures and output image should be in gamma space. Also, maybe some parts of rendering such as UI compositing should happen in gamma space because it's more familiar to artists (it works more like Photoshop layer compositing and such). Also, we have to decide if internal render targets are going to be stored in linear or gamma space, as it will affect precision. And we have to get all the conversions right, so that data gets converted between linear and gamma at the right spots in the rendering process.
