Other formats overview:
ACIS is one of the two most popular geometric kernels, powering a lot of CAD, CAM, CAE, and AEC software. It's more than 30 years old, having been originally created in the '80s and is currently developed by Spatial (part of Dassault Systemes). Like any other 3D geometry kernel it provides a basis for the engineering and design applications in the form of data structures to represent 3D models and various geometric algorithms to operate on them. To enable saving and loading of 3D models in between the modeling sessions it exposes a persistence format, called ACIS-SAT (or simply SAT). It used to be an open format with publicly available specification around the 2000s, but the later revisions are not.
ACIS files come in 2 flavors - text (SAT) and binary (SAB). Fig. 1 depicts the example ACIS-SAT file in text format. The structure for both flavors is the same - a short header with basic information about the model and then an indexed list of entities. In the text flavor, each entity starts with a type name, followed by a list of parameters, followed by the pound sign (#), designating the end of an entity. The tradeoff between text and binary flavors is quite standard: text files provide readability and an ability to manually tweak the contents of the model, but are larger than binary and suffer from the round-off errors related to the textual representation of numbers.
ACIS-SAT provides a fully-fledged data model for B-Rep geometry with every possible topological entity - from solids down to vertices. This ensures that the connectivity of design is preserved and that solid models are watertight. Aside from solids, ACIS-SAT can represent sheet and wireframe bodies, and even hybrid models consisting of multiple bodies of different types. It can also hold so-called non-manifold topology, two standard examples of which are an edge shared between three faces (cf. Fig. 2, left) and an infinitesimally thin bridge between solids in the form of a single vertex (cf. Fig. 2, right).
ACIS-SAT can store simple parametric curves and surfaces, such as lines, circles, spheres, cones, etc. It also provides multiple entities that represent curves and surfaces created from modeling operations - intersection curves, swept, blended and skinned surfaces. They contain the information allowing to compute these geometries exactly from the modeling operation parameters but also sometimes contain approximate NURBS geometry.
Naturally, the biggest advantage and reason to use ACIS-SAT format is its close relationship with the ACIS kernel. The entities of the format closely follow the data structures, in which ACIS holds the geometry in memory. This means that no translation needs to happen when an ACIS-SAT file is read by an ACIS-based application - the contents of the file are simply mapped straight into the objects in memory. It's fast and if the file is written correctly, also allows for a better accuracy of the model, since there's one fewer translation along the way.
When it comes to other types of data, not immediately related to geometry, the ACIS-SAT is less feature-rich. It allows storing multiple bodies in a file and attaching colors, names and even arbitrary attributes to the geometry in the form of key-value pairs. On the other hand, it does not provide facilities to represent the part-assembly hierarchy (arguably the biggest capability it does not have, cf. Fig. 3) or mesh models.
The closed specification, focus on the B-Rep geometry and topology and lack of part-assembly hierarchy facilities determine the ACIS-SAT role mainly as a persistence mechanism for ACIS-based apps and a vehicle to feed the data into ACIS-based apps. When the ACIS kernel is not involved in the data pipeline, another format, such as neutral STEP, might be more suitable.