Application architecture questions

This would greatly depend on Data Model demands of your application. OCCT comes with:

• BinTools and BRepTools implementing persistence for TopoDS_Shape (without any extra data), e.g. for saving shapes in files.
• OCAF defines fundamental bricks for implementing your own Data Model with TopoDS_Shape persistence with arbitrary attributes and other data. It also defines low-level Undo/Redo mechanisms.
• XCAF defines document structure based on OCAF for Data Exchange - e.g. shapes with colors, materials, validation properties, PMI, metadata. Mostly fllfills capacities of STEP standard, but includes some other features. It is possible extending XCAF document at application level, but this customization should be done carefully.
• TObjdefines object-oriented tools on top of OCAF for implementing application-specific Data Model with shapes, Undo/Redo, persistence. It provides a more clear and straightforward mechanism than using low-level OCAF bricks directly.

As such, you need first to understand which information you would like to store in your document, how many application-specific attributes and data it will hold and which operations should support.

E.g., if Data Exchange is your main focus, than XCAF is preferable document format compatible with all XDE interfaces in OCCT (STEP, IGES, OBJ, glTF, VRML) and having it's own persistence (binary XBF or textual XML). But it is not that extensible and might be difficult to modify.

If you have a lot of own data objects or completely different document structure - then it might be better starting with TObj (it is quite convenient interface, but you might experience some lack of live examples and tutorials - I've been working with it having a look at existing projects using TObj, a great cheat sheet of good practices). Dealing with low-level OCAF might be even more challenging for newcomer (but I have no personal experience on that).

Of course, you may end up implementing you own Data Model and rely on BinTools and BRepTools just for file persistence of TopoDS_Shape - this is what FreeCAD developers decided to do (with own XML file format), as far as I understand. But in this case you will have to implement Undo/Redo/Transactions mechanism on your own (if your application requires that).

As for original question of inheriting TDocStd_Application - there is no much reason to do so, you may use this class directly. Previously, subclasses of this class did some extra work to define persistence drivers (as dynamically loaded plugins, with extra files defining mappings), but nowadays file formats could be specified externally, so that subclassing is not that necessary.

One exception is TObj_Application which defines a couple of extra routines (you will need this class, if you'll work with TObj. Or XCAFApp_Application for XCAF.