The traditional use-case for Sling Models is to provide a business abstration for a resource or request, which provides HTL scripts (or, previously JSPs) an interface for accessing business functions.
Common patterns are developing Sling Models that represent AEM Components or Pages, and using the Sling Model objects to feed the HTL scripts with data, with an end result of HTML that's displayed in the browser.
This traditional pattern works well in the context of generating HTML as the Sling Model can be easily leveraged via HTL. Creating more structured data such a JSON or XML is a far more tedious endeavour as HTL doesnt naturally lend itself to the definition of these formats.
Apache Sling Model Exporter comes with a Sling provided Jackson Exporter that automatically serializes an "ordinary" Sling Model object into JSON. The Jackson Exporter, while quite configurable, at its core inspecs the Sling Model object, and generates JSON using any "getter" methods as JSON keys, and the getter return values as the JSON values.
This flow describes the flow using the provided Jackson Exporter to produce JSON output. Use of custom exporters follow the same flow but with their output format.
While the Apache Sling project provides the Jackson Exporter that serializes Sling Models to JSON, the Exporter framework also supports custom Exporters. For example, a project could implement a custom Exporter that serializes a Sling Model into XML.
Not only does Sling Model Exporter serialize Sling Models, it can also export them as Java objects. The exporting to other Java objects does not play a role in the HTTP Request flow, and thus does not appear in the above diagram.