The above is me switching between Eevee and Cycles on an imported alembic file where I’ve just used geometry nodes to set point radius and put a glass shader on it and nothing else.
Why does Cycles render the points as spheres while Eevee renders them as diamonds? Is it possible to increase the Eevee point tesselation anywhere?
You could instance a sphere on the points to override the default octahedron. Do note that eevee is much more sensitive to polygon count that cycles, as it cannot instance objects in the same way, which is probably why they tried to minimize the polygon count by default.
Also, if I’m not mistaken, Cycles calculates perfect spheres which aren’t made of polygons by tracing rays against the points directly. Eevee works differently, as it’s not a raytracer, so that likely explains the difference.
I think that’s because the developers always try to maintain compatibility with older hardware (at least in eevee.. cycles is only for - not so old - gpus) . I think that’s very nice (since I have crappy and quite old hardware myself - gpu especially - BTW: not supported by Cycle - ).. but it would be better to have the OPTION to add a bit more detail (at the cost of some computation time) when your GPU maybe could, in EEVEE too (like it’s with shadow - rays and steps and whatever -, samples, and all customizable parameters when rendering with EEVEE )
Cycles does render points as spheres at least back to 3.6..
Also:
If if one could use points directly as mesh usually one use the Instance on Points node to.. instance some geoemtry, because points would be infinitesimal small.
So implicite instancing something is nice but the different render engines (raytracer vs. polygon renderer) does implement this differently.. like so much other things too. 
(So this has nothing to to with compatibility…)
Is that as close as we’ll get to a true (very old school) CSG renderer? I don’t use Eevee but I’m a bit shocked it can’t handle these. So useful for certain things.
Even if Cycles can render CSG spheres, I have had serious issues shading them properly, especially volumetrics and overlapping transparencies (think planet sim with infinite spherical resolution).
I’m not an expert on this topic, but I think what Cycles is doing is a simple ray sphere intersection. So it’s in the same broad category, but there isn’t a system in place to calculate more complex interactions between primitives.
Eevee is a newer renderer, not as feature rich as Cycles, and Cycles couldn’t handle particles as spheres either for the longest time.
I’m not surprised Blender cannot support this modeling method, as there is only so much developer time and room for features in the software. What gets focussed on is the more popular and practical pipeline.
Is this really needed? Past a few levels of subdivision, you can zoom in on a sphere as much as you want and you won’t be able to see the angle between faces. Especially if you use adaptive subdivision.
That’s what CSG (for me, anyway) was all about; simple ray “geometric formula for various shapes” intersection. It could do boolean unmatched (never any “mesh cleanup” needed to get good shading, and infinite geometry resolution at no cost, but also no UV).
As for “needed”, more of a novelty “nice to have”. Of course workaround exists, but on a couple of (non professional) occasions have I gone “this would be so much more convenient with CSG”. Since several decades old, I’m not seriously asking for CSG capabilities. But if sphere is already in, why not make it adhere to regular shading concepts in a proper way? It’s been a while since I tested, but I don’t think I’ve seen any updates on this mentioned.