DAML on SQL and the participant index both store transactions as individual nodes, so that they can be filtered down according to privacy rules at the storage level to minimize the data moved around.
Each event has a set of structured data associated with it (like the identifier of the transaction or of the contract on which the event occurs), plus a few Protobuf-encoded BLOBs which represent DAML-LF values: contract creation argument and key for create events, exercise argument and result for exercise events. One of the reasons that lead to this choice is that our libraries to handle DAML-LF values already provide a way to seamlessly read values persisted in an old version of the encoding, to ensure transparent backwards compatibility. I would say there isn’t much to gain from storing these values in different formats.
With regards to “various DAML ledgers”, the interface between the participant and the ledger storage is defined in terms of DAML-LF transactions. Ledgers can decide to store full transactions as Protobuf BLOBs, find a way to store each piece of information in a structured (or semi-structured) fashion, or somewhere in the middle of the road (as DAML on SQL does). There isn’t anything in the interface that forces any specific approach, but different approaches have different pros and cons (in our case, the pros for our approach were facilitated backwards compatibility and pushing down Ledger API predicates, where a con could be not being able to perform more granular queries on individual contract fields).
As mentioned in the very first answer, this is entirely an implementation detail which no user should rely upon, if not for internal maintenance of components. The Ledger API is the only reliable gateway to the data stored on DAML ledgers.