Let’s solve your data problems.

From Rob – “Replace” is a strong word that I personally would hesitate to use, but maybe Justin would disagree. Going one level deeper on my own thoughts: to the extent that data lakes were already replacing data warehouses, I think that’s also true for Fabric/OneLake. And the data lake “advantage” over SQL-based warehouses was/is essentially this: you don’t have to think as hard about schema and design with a data lake. Data coming in can be “dumped” into a data lake with a lot less thought, in its raw form (or close to it), without fear of losing information, and without fear that the storage format will preclude you from achieving goals down the line. I think of it as “turning raw data into rectangles.” (Aka tabular schemas). Data often doesn’t “arrive” in rectangular form. (ex: XML, JSON, folders of inter related CSV’s). SQL warehousing requires you to design all of the rectangular shapes UP FRONT, and that’s both a dangerous and expensive process. The translation itself (from “curly” things like XML/JSON/CSV) risks “losing” important information that was present in the raw form. So you spend a tremendous amount of time on that process – and still get it wrong. If we could skip all that, it would be great. You always EVENTUALLY need rectangles – analysis by its very nature operates on the things that are regular about your data – but delaying that “rectangularization” until later turns out to be super smart, and OneLake gives you exactly that. Dump and store in raw form, and then extract whatever rectangles you need later. But if you already have data in SQL format, there’s not much to gain from data lake storage – except that now, if you load it into OneLake, it’s now “on the highway” that exposes your SQL-originated data to basically every single analytical service MS has to offer. 
 

From Justin – My answer here is definitely yes, but not discounting Rob’s comments here that an actual EDW represents a rather mature state for any organization that may not be practical or necessary. There are two different SQL artifacts in Fabric, the SQL Endpoint on the Lakehouse and a SQL Data Warehouse. The former is essentially read-only with schema generated automatically from the Lakehouse. The latter is fully ACID compliant with full transaction support, and full DDL and DML functionality – built on the Synapse Infrastructure and can most certainly serve as an EDW. The storage layer underneath is still an open delta format, so you retain the full benefit of flexibility to other Fabric artifacts, as well as external platforms.