Since this is 1995, pixels didn't map 1-to-1 to phosphors on the CRT. Now with LED and LCD displays they do. Not that this invalidates the paper, but it certainly adds some context.
I think manufacturers don't have a solution to this because the light producing elements inherently produce light across a small surface. They can't make this surface much smaller (and then apply a good blurring filter) since that would incur directly less brightness. Also, if they could, it would probably be more costly then simply making a larger number of smaller pixels (which also raises resolution).
I'm sure a lot of manufactures are not even mindful of these issues though, and I ssupect a compromise would be possible with some R&D.
EDIT: It's interesting this phenomenon is about the same across time. Some high-end monitor manufacturers are starting to offer strobed high frequency displays that don't exhibit the poor response of a window reconstruction. With a high enough refresh rate the temporal time constant of our visual system is enough to provide a good reconstruction. The difference can be seen in this video: https://www.youtube.com/watch?v=zjTgz9byxuo
Having used a CRT for many years and then switching to an LCD, I disagree; one of the major "wow" moments for me upon looking at an LCD for the first time (at native resolution) was how sharp and crisp everything was compared to the ill-defined blurriness of the CRTs I'd used before. I was finally able to see pixels as "little squares" (even their corners were discernable) and not the vague blobs they were before. Trying to use a CRT again for anything but picture-viewing (which naturally doesn't require the same level of sharpness) feels like my eyes can't focus and I need new glasses.
(That video was terribly nausea-inducing; definitely needs a warning.)
http://www.displaysearchblog.com/2013/03/how-did-samsung-ach...
More precisely: now there is somewhat a more common case where they do. Certainly in many contexts it is still helpful to think of pixels as points (images are very often transformed before display). But if you're talking about what gets pushed to the screen, it probably will be helpful to think of them as squares. Doing so lets you do cool tricks like sub-pixel antialiasing.
And sure, you could still deal with subpixels in a "pixels are samples" model, but it would be a lot more awkward.
LCDs are very digital in nature. My display here has exactly 2880 "cells"(not sure exactly what we call them) for each of the RGB colors in one horizontal line. For a cell to emit light it has to have current run through it. That makes every cell on my LCD individually addressable. The interface between the computer graphics card and the LCD driver logic is completely digital—each group of 3 cells (RGB) is individually specified. If you're running the graphics driver in this "native resolution" then 1 pixel on the screen corresponds directly to these 3 little LCD cells.
Now, some LCD screens aren't like that—some have weirder pixel layouts[1], but they are still individually addressed, unlike the phosphors (or shadow mask holes, I guess) on a CRT.
Am I right to think that you'd only use square windows in the 3D-rendered graphics case, where you've already assumed the sub-pixels are square for efficiency?
Take for instance a ray tracer. Each ray is a sample and these are cast from the focal point, through the view frustum, and the colour is calculated where it intersects an object in the scene. In the naive case, this is done through the precise centre of each pixel, so there is a one-to-one mapping between display pixels and rendered pixels.
However, that leads to very bad sampling error (aliasing), so typically you instead take lots of samples (which throws up more problems of sampling bias which I'll ignore for now). Now you have to decide how to map those samples to screen pixels.
This is where the phrase "a pixel is a window" comes from. If the point sample falls within the current pixel boundaries, it's a contributor to its value. Pixels are generally considered to be rectangular windows, because that maps nicely to the way they are laid out in a grid.
In particular, when displayed on-screen, each pixel represents a rectangular area of the screen. However, that's independent of how the image data was quantised originally.
The point the paper seems to be making is that this rectangular mapping isn't very good, and overlapping circular windows are better. That's debatable and it depends what you're doing. With this model some point samples are contributors to more than one screen pixel, but on the upside, contributors to each pixel are all within an equal distance from the midpoint. A square allows samples that are further away on the diagonals, which is not right. It's correct for display, but not for manipulation.
Either way, a pixel is still a window. You can choose different shapes for that window, with different trade-offs, but a pixel still describes the average of samples within the region it covers, rather than any single sample. That unfortunately is then quantised into a single sample for the pixel, ostensibly at its midpoint.
Of course, the bigger problem is that quantisation step. If each point sample were stored as a vector, you could have lots of randomly positioned samples and re-quantize them into any shape pixels you like, which might be useful for something like the barrel-distorted projection used in the Oculus Rift, where it would be advantageous for every pixel to have a unique size and shape depending on how close it is to the centre (or think of a spherical projection where it also makes sense for pixels to be non-square).
Unfortunately, that's not the way pixels are represented in any image formats we have, which is the particular view of pixels the paper is concerned with.