My background is in video engineering and the point I'm making here is very specific. It only applies to hand-crafted retro game pixel art created in the CRT era. And my point isn't even about CRTs! It's about how the RS-170A composite video standard that CRTs used encodes color. The "A" in RS-170A added color to the existing black and white television standard while remaining compatible with old B&W TVs. It was sort of a clever analog-era compression hack. I'll skip the technical details and history here (but both are fascinating) and simplify the takeaway. Broadly speaking, in digital representations of composite video color encoding, the correct color of a pixel can only be known relative to the current phase of the pixel clock and the pixels adjacent to it. Sometimes it's a fairly subtle difference but other times it can change a pixel from blue to red.
To be clear, this wasn't "better" in any way (other than allowing optional color). The "hack" of encoding chroma information at half the frequency of luma and only in relation to a sub-carrier frequency came with trade-offs like chroma fringing on high frequency edges, ringing and other spurious artifacts. However, it was the only video we had and video game creators of the 80s & 90s used the tech they had to create the best images they could. For example, we would put a pixel of a certain color next to a pixel of another color to intentionally change the color of the second pixel (and NOT just due to blurring the two together, it literally decoded to a different third color). I did this myself in the 1980s, intentionally positioning a white pixel next to a black pixel on an even numbered column so they would show as a single red pixel on the screen. Using this encoding technique, I could display 9 different colors from a computer that only had two bits per pixel. That's why just displaying a naive RGB output of the game isn't properly decoding a signal that was hand-encoded to have more and different data than what's in the naive RGB.
So I recommend using a CRT shader not because it emulates a glass tube with phosphors but because it includes the decoding logic to correctly display the original encoded content. Personally, I never use the shaders that add noise, blurring, cross-talk or other degradation. That would be as dumb as adding the pops and click of a dirty vinyl LP to a pristine signal. That would make it less accurate. My goal as an engineer is to be more accurate. It's fine if adding spurious crap tickles somebody's nostalgia bone from when they were a kid - but I'd never do that. I want to to see the original pixels and colors the artists saw and intended their audiences to see. That requires properly decoding the signal. And the example I posted demonstrates just how different an image can appear when properly decoded.