> The paradigm shift from ETL to ELT is what went wrong with Data Lakes.

It wasn't exactly the shift from ETL to ELT, it was the stated goal of putting "T" on read with no intermediate schema.

In my experience, it's always (since way before data lakes) been a multi-step process and I don't know how it's even possible to do the data lake strategy without re-creating a ton of transforms over and over:

1-Extract

2-Possibly do some transforms early due to specific operational/technical reasons

3-Load - even before "ELT" became a term, load without transform was happening due to constraints, like the transforms requiring data from separate operational systems to even be possible

4-Transform 1 - Foundational stuff like converting unique operational schemas (due to technical or functional reasons) into more natural schemas, easier processing in later steps

5-Transform 2 - Unifying core data that spans multiple operational systems (e.g. order fulfillment txn appears naturally in different systems but for different/overlapping business reasons and with some differences in identifiers and attributes)

6-Transform 3 - First pass at foundational target state

7-Transform 4 - Possibly more, or possibly not

8-Consume valuable data