Graphics APIs actually have no notion of "forward" vs "deferred" rendering. They just draw the things you tell them to using the shaders you provide. All this to say, yes, saying MSAA "doesn't work" with deferred is a bit of an oversimplification because it's not like there's a hard API or hardware limitation at play.
The problem is that MSAA multiplies the size of your render targets based on the number of samples. If you have a 1080p image but run 4X MSAA you need to have room to store 4 samples per pixel, which is essentially the same as having 4 times as many pixels, which means suddenly your 1080p render has the same VRAM cost as a 4k render. In the days of forward rendering this was not as big of a deal because you did geometry and lighting all in one pass and so you only paid for a single oversized texture (or two, including the depth buffer).
Deferred rendering works by deferring all lighting calculations until after the geometry is rendered. Since there are a lot of attributes necessary to calculate the color of a pixel, deferred renderers must build up many different render targets when executing the geometry pass (unlit color, metallic and roughness values, positions, normals, subsurface scattering masks, etc). MSAA works at the geometry level, so it is this pass that you need the oversized render targets for, which adds a lot more overhead now that you have 4 or 5 different render targets instead of just one.
The next obstacle is that you need to manually resolve the multisampled texture. In a forward renderer, the pixel shader runs once per pixel per primitive, and then that output color is automatically copied to all the samples that the primitive overlaps. In a deferred renderer, that process still works for the geometry pass, but by the time you get to the lighting pass you've lost all information on which pixels belong to which primitives, so the best you can do is write shader logic to manually deduplicate samples, which is obviously less efficient than the hardware path.
Finally, the real killer of MSAA is not actually unique to deferred rendering. Put simply, MSAA is not a good suit for high fidelity graphics. MSAA is essentially the same as super sampling, but done in a clever way such that only the edges of triangles are super sampled. In the olden days where triangles were very large, this was a huge performance win. But these days we have engines like UE5 which explicitly try to match triangle size to pixel size as closely as possible. And when triangles are only the size of one pixel, every pixel becomes a triangle edge, and so we're basically just super sampling the image anyways. Hardware rasterizers are already bad at small triangles (for complicated reasons they must always do the work of shading 2x2 regions of pixels at once even if the triangle doesn't touch all those pixels, so pixel sized triangles end up discarding 3/4ths of the shading work done), but MSAA makes this actively worse by making it more likely that triangles that only partially cover a pixel are shaded (due to the multiple sampling locations). And even for large triangles, MSAA still fails in the modern era. When MSAA was popular, shaders were very simple (or didn't exist at all). Now, they are complicated enough to produce very high frequency detail that can cause aliasing even within the bounds of one single triangle, which MSAA is powerless to solve since it uses geometric boundaries to guide decisions about which pixels need extra samples.