Geoms can handle objects built using any of the allowed segment types, including arcs (curvilinear segments like circle, ellipse, or spline arcs). The reason arcs aren't so good for GIS users isn't that they can't be attached to data just like linear segments, because they can. The main reasons are:
1. Interoperability - Most GIS programs and vector formats can't handle, or have various limitations, on using arcs. Create a drawing that uses arcs and you limit your ability to interchange that drawing with other packages. There are no splines in shapefiles, for example.
2. Projections - A spline is defined by a mathematical formula based on the anchor points it uses. Those anchor points are just XY locations in whatever coordinate system is being used. But a spline that looks like you want in one coordinate system isn't going to look the same way if you simply transform the coordinates for the anchor points into the new coordinate system. Yes, you expect the spline to be visually different in the new coordinate system, but just transforming the anchor points using the formulae that are used to define coordinate system transformations doesn't get it right. There's a very big world of coordinate system transformations (NTv2, EPSG, etc) that are not a good fit to reshaping things like splines.
There are smaller reasons such as various epsilon considerations to decide when, for example, two splines or other curvilinear arcs intersect, etc.
But the upshot is that when you start using curvilinear segments, you tend to get away from the interoperability and re-projectability that people expect in GIS, and you also tend to get away from being able to use the algorithms that work with classic GIS linear segments for things like topology overlays and other spatial manipulations. There are ways of getting around that, for example, rewriting code to always interpolate splines and such into a sequence of very many linear segments, but then you're not really using or preserving splines.