It's tempting to think that faster storage and Direct Lake make modeling discipline less important — if queries are fast regardless, why bother with a clean star schema? In practice the opposite is true: the faster the engine, the more a sloppy model costs you, because performance problems stop being the thing that masks modeling problems.
The fundamentals haven't moved
A clean star schema — narrow fact tables, conformed dimension tables, single-direction relationships, no bidirectional filtering unless you have a specific reason — still produces simpler, faster, more maintainable DAX than a wide, flattened, snowflaked alternative. Fabric changes where the data lives and how fast it's queried, not how filter propagation or relationship cardinality works.
Where Fabric does change the calculus
What is different is the cost of getting your dimensional model wrong upstream, in the Lakehouse. With Direct Lake, your semantic model's tables map closely to your Delta tables — so a poorly structured Lakehouse table becomes a poorly structured semantic model table, with none of the transformation layer Power Query used to give you as a buffer. Star schema discipline has effectively moved one layer earlier, into how you design and write your Lakehouse tables.
Practical takeaway
Design your dimensional model on a whiteboard before you write a single Spark notebook or DAX measure. Decide your grain, your dimensions, your fact tables — the same exercise BI people have done for twenty years — and only then start building the Fabric items that implement it. The platform changed; the discipline that makes it usable didn't.