I think a grid of regular hexagons would do a pretty poor job of reproducing horizontal and vertical lines, which are pretty common in computing. On one axis, you can have an uninterrupted single-pixel line, but it will have triangular edges. On the opposite axis, you wouldn’t be able to have an uninterrupted single-pixel line. You’d either have to live with a dotted line or a minimum width of two pixels (which will be even more jagged than the other).
Oh, and anamorphic videos are recorded with the intention of playback on non-square pixels.
Cite? 
(For the “computationally more expensive”, not the “best display.”) While certain procedures may be intricate to design, once designed the hexagon version is often simpler and faster than the rectangular counterpart.
Simplicities of the hexagon grid have led to its adoption in some cases (e.g. for its simpler connection topology as in a random example at top of Google results). There would be various advantages in ordinary imaging. (Note that, while vertical lines might be slightly harder to depict, lines at other orientations would be depicted slightly better.)
Contradictory. If computation expense were the issue, increasing number of pixels would not be the solution. Indeed, hexagon grids require fewer pixels for a given (suitably defined) effective density.
There was a flurry of interest in hexagon-grid images ca 45 years ago. In 1968 Perkin-Elmer even built a special computer (GLOPR) to process hexagon images. Googling for a good cite on that I find almost zero – can anyone find a good cite? (I find a few, mostly citing the GLOPR algorithms for application to rectangle or pseudo-hexagon grids.) The Wiki article on Golay himself doesn’t even mention his work with hexagon grid. 
This is the key point. “Optimality proofs” do exist, but the investment in rectangular “infrastructure” may have too much inertia to overcome.
IIRC, my grandparents old (maybe 1960s) TV had pixels as equilateral triangles.
Chronos put this better. It would be computationally expensive to convert on-the-fly from a huge infrastructure of code and resources that assume square pixels.
Good point! It would be computationally expensive for the early adopters, for the reason above. But it would probably be the extra engineering costs that would dominate any attempt, rather than the computational ones. You have an excellent point that even if it’s less efficient, it would be O(N), whereas increasing dots per inch is O(N^2).
What I should have said is that it’s unlikely to happen today, since we’ve reached such high pixel densities that the advantages would be minimal.
Also a good point. Little-endian has a slight advantage over big-endian, but god oh god I wish nobody had EVER thought of it!
Just the color ones. 
Triangular because each one had one dot of each of the 3 colors.
The difference there is that the scanning was analog, so it didn’t really matter how the phosphors were placed, as long as the result worked. That is, the beam of electrons from the cathode doesn’t care whether it hits phosphor or mask.
They were still aligned in a rectangular grid.
Assuming the pixels were regular (i.e. not some weird organic completely un-gridlike dither pattern), I don’t believe it really would be that expensive to compute - it would be the job of some sort of display apparatus or driver - but really, it would be bread and butter for even the average GPU.
I don’t think device or driver complexity is the issue. More complex transforms already occur; cameras already do grid transformations, albeit from one rectangular grid to another.
The problem is integrating all the devices and software of a system. Using hexagonal grid on input and output devices but rectangular image processing software in between would almost miss the whole point: The elegance and speed of processing algorithms are a “big win” for the hexagon grid.
I think Learjeff hits the nail on the head:
Speed, density and low cost make theoretical disadvantages almost irrelevant.
Still, I’ve wondered if hexagon grids would be appropriate for some high-cost applications. A colleague consulted on the design of towed oceanic seismic sensor arrays, where each “pixel” is an expensive sound detector costing millions of times more than a camera pixel. I suggested he place the sensors in a hexagonal array instead of rectangular. He [del]looked at me like I’d farted. :p[/del] mentioned something about 2-D Fourier transforms. I mentioned 2-D Fourier for the hexagon grid, but it was a lost cause.
For video (SD and HDV) they often don’t have square pixels.
Also for 320x200 (which was popular for old games using CGA, EGA? and VGA)… the entire image is 4:3 and if it did use square pixels it would have been 320x240. (so the height of 200 has been stretched to 240).
Sure, but until everyone is using that standard (which may be a long time or never), there would inevitably have to be some conversion/rendering on the fly - many/most of the common computer image formats are rectangular raster-based - and some things are always going to want to use an XY coordinate system, but as I think we both agree, transformation on the fly would not be computationally expensive by modern standards.
And tessellation is the answer. Rectangles (a square being a subset of rectangles)are the only shapes that tessellate without any transformations and completely fill a rectangular area. you don’t want to have odd gaps at the end or have to deal with pixels that are harder to see than others due to half of them being covered up.
Sure, we just could do alternating right triangles, but that means that every other pixel is different. And the pixels being different means much more complicated calculations for conversion, as you have to consider where exactly the object is located on the screen. And while that is done a lot, it is not done all the time for the fastest types of pixel rendering.
And even if it is feasible to do now, it sure wasn’t when development started. A lot of older computers were maxed out just moving sets of pixels on screen. They couldn’t take the burden of converting back and forth.