Arcs

The toolchain for 3D printers is broken.
By that I mean there is a fundamental flaw in it; at least for regular geometrical objects. The process is good for Yoda heads and other objects extracted from 3D scans, but it fails for designed objects that have anything other than rectilinear forms.
The fundamental problem is using STL files as an intermediate format. The contents of this file type is a series of triangles that describe the exterior boundary of the solid. If the design that creates the STL files has a cylindrical, spherical or other curvilinear solid body, the program that generates the STL file has to approximate this with a tessellated surface. Even very simple solids can generate thousands of planar faces in trying to represent the design in the limited vocabulary of planar triangles.
As an example, consider the simple cylindrical object and its STL equivalent:

Obviously, storing the three coordinates of each of the three triangle vertices and three direction numbers for the normal, takes considerable storage. This STL file is 100KB for an exceedingly simple object. This is the result for a high resolution output, but reducing the resolution causes more deviation between the flat triangles and the original object - in other words the printed object is not what was designed; holes get smaller, you can see facets instead of smooth surfaces, etc. As the hole size gets smaller the facets need to get smaller to keep the surface deviation small, so the number of facets is mostly independent of the scale of the object.
The problem is, downstream programs like ReplicatorG, Cura and Slic3r need to process all this crap data. The generated G code file for this example is 750KB. This is why slicing takes so long and baud rates to the machine need to be as high as possible.
There is a possibility to use arc G codes (G2 clockwise arc, G3 counterclockwise arc) with Marlin to reduce the number of G codes needed to print circular objects, but the only program that even tries to generate these G codes is Slic3r, and that is only an "experimental feature".
Why? Because it's a hard problem to reconstruct the original mathematical shapes that created the STL file. A long time ago, my professor said "You should always tell downstream programs what to do, not have them try and figure it out." That has proved out to be true time and time again. This means the instructions to the slicing code should be as rich and explicit as possible, rather than have the slicing code try to figure out what the intent is.
Certainly, eventually, there will be technology to reconstruct solid models out of STL files, but like colorizing black and white movies, or performing raster to vector conversion, the result is never as good as having the original data.
Why are we throwing out the information that can make 3D printing simpler? Why not start making color movies today and create (or adopt) a real 3D format for the use-case of printing designed (rather than scanned) objects?
The problem is, there are many formats (e.g. IGES, STEP, etc.), and figuring out which one would be best for the 3D printer community is also a hard problem.