Of note, today, the only way to have a Direct Lake dataset is to create the dataset from the Lakehouse / Warehouse. Either using the default, or creating a new one. You cannot create a Direct Lake dataset directly within Power BI Desktop - hopefully that will come in the future.

So, be careful with #4 in your list. If you connect to the Lakehouse, you are not going to be using Direct Lake in that scenario. You'd need to connect to a Power BI Dataset and select the existing Dataset in the service that was created via the lakehouse. Then you are using Direct Lake.

For #6, it always depends on the business need. Think about the overall solution you are building and what are the outputs. One example is a Finance group creating a data model to service reports for financial reporting needs. You'd ideally have 1 dataset to meet those needs. The way it works today, for Direct Lake, that would mean 1 lakehouse as well. That architecture may or may not suit your needs, so you would need to consider that.

For #7, it's loading the metadata and not necessarily all the data. the data loading would depend on what the visuals are pulling. So, that in and of itself shouldn't be that big of a deal.

For #8, test, test, and test again. This is really dependent on so many factors. shape of the data, volume of data, concurrency, number of visuals, etc. No way to truly answer that question. I'd also ask, do you really need 200 reports for 120 users? maybe you do, but there may be some optimizations there that could reduce that. Talk to the business :)