Flat objects are the right shape when the source data is naturally tabular and the consumer expects to iterate rows independently. Analytics tools, machine learning data loaders, simple report renderers, and CSV-like ingestion endpoints all expect this shape. Imposing nested structure on naturally flat data adds friction for these consumers without adding value. FixTools defaults to flat output when you use plain headers, so this is the path of least resistance for tabular data.
Flat output round-trips back to CSV cleanly. If you convert CSV to JSON and then later need to convert back, the JSON to CSV step is deterministic when the JSON is a flat array of objects with consistent keys. Nested JSON requires flattening logic during the reverse conversion, which can be ambiguous or lossy. Keeping the JSON flat preserves the option to round-trip back to a spreadsheet for human editing.
Predictable schema is the third virtue of flat output. Every object in the array has the same keys (assuming every row had values in the columns). This means consumers can safely access keys directly without checking for the existence of nested parents. A consumer that reads obj.firstName works for every record. With nested data, consumers need to check obj.contact and then obj.contact.firstName, which adds boilerplate to consumer code.
For datasets that are intrinsically hierarchical (orders with line items, customers with addresses), flat output is not the right choice and you should use dot-notation headers to build nested objects. The distinction is about the natural shape of the data, not a preference for one form over the other. FixTools supports both shapes and you pick based on what the data actually is.