Transform before you load and you throw away what you didn't anticipate; load first and the warehouse does the work, but it stores your mess.
Sort the shopping in the car park and carry in only what you planned to cook, or carry everything into the kitchen and decide there. The second lets you change your mind.
Whatever the extract step drops is gone, and the question nobody asked yet is the one that will need it.
ETL transforms data on the way in: extract from the source, reshape it in a separate compute layer, load the finished tables. That was the right design when warehouse storage and compute were expensive and coupled. ELT loads the raw extract first and transforms inside the warehouse with SQL. Cheap object storage and elastic warehouse compute flipped the economics, and the consequence is bigger than performance: with ELT the raw data is still there, so when someone asks a question your transformation didn't anticipate, you rebuild rather than re-extract. The trade is that you now store raw data — including everything you would rather not have kept.
ETL transforms before loading, in a separate engine; ELT loads raw and transforms in the warehouse with SQL. ELT won for analytics because storage is cheap and warehouse compute is elastic, and because keeping the raw extract means you can rebuild any model without going back to the source. ETL still wins where you must not land raw data — PII you can't store, or a source you can only read once.
ETL vs ELT: Powering Data Pipelines for AI & Analytics — IBM Technology, 6:51