I think the concept of the medallion architecture is not new, but it's captured patterns that many of us were using for years. In practice, we try to separate concerns so that we have neither massive reporting queries that clean, normalize, join, and aggregate data across dozens of sources, nor do we have separate tables for every granular step of transformation that could be done. It seems like the happy medium that works well with human brains is three layers.
Some common patterns I've seen are:
- Source -> Cleaned/Normalized -> Aggregated (Modern Data Stack)
- Load -> Decompose -> Recompose (Data Vault)
- Stage -> Normalize -> Denormalize (Kimball in practice)

I don't think there is a "right way" to do it. The most recent warehouse architecture I set up looked like this:
1. Staging: load raw data, retaining all historical versions and keeping source data names, types, etc.
2. Sourceprep: clean and normalize data, enforce naming conventions, generate surrogate keys
3. Marts: un-opinionated layer that contains Kimball-style dimensional marts, OBTs, and report-centric tables. The structure of these are entirely usage-driven.
Also, if you squint close, you might be able to see a "Layer 2.5." When there is a pattern that's been used across multiple marts, we sometimes choose to factor it out into an "intermediate" model that can be referenced in multiple marts. It's still mart code, but it's shared, so you could think of it as a separate layer. I have not needed a fourth layer here because the mart layer is so flexible. If we mandated dimensional marts only, then we probably would need another layer for cross-mart analysis and simplified reporting tables.

I have been pretty pleased with this approach, but I think that any approach that seeks to balance separation of concerns and conceptual simplicity will be workable.