Evaluate a Proposal to Replace the Star Schema With One Big Table

Your team runs a Kimball-style star schema on Snowflake: fact_sales (grain: one row per sale) joined to dim_customer, dim_product, dim_store, and dim_date. A new analytics engineer proposes replacing it with a single wide table, sales_obt, that pre-joins every dimension attribute directly onto each sale row, arguing "this will make every dashboard query faster and simpler, and storage is cheap — let's just flatten everything."

1. Under what conditions is this a good idea, and under what conditions is it likely to cause real problems? Be specific to this schema, not generic.
2. dim_product.category is Type 2 (versioned, because products get re-categorized and historical reporting needs to reflect the category active at time of sale). What has to be true of sales_obt for it to preserve this correctly, and what happens if the team just does a naive SELECT * FROM fact_sales JOIN dim_product ON ... without accounting for it?
3. Propose a middle-ground architecture that gets most of the query simplicity benefit without abandoning the star schema entirely.