Most if not all of what is posted above is in the https://learn.microsoft.com/en-us/power-platform/guidance/coe/starter-kit. I highly recommend going through these docs.
Also worth a read: https://adoption.microsoft.com/en-us/powerplatform/
This is a tough choice, that you need to carefully consider. MS positions everything as 'open', which means you're going to get a LOT of people making things in the Default environment with 'standard' connectors only as people have E5; no premium. This means Canvas, no model (needs dataverse), Power Automate (Office M365 Collaboration tools integration only for the most part), no Environment data persistance, aka Dataverse.
Basically, the Power Platform will be available to build on or extend M365 functionality for the most part.
You have to make sure you understand what the impact is on your team and what the capabilities are that are going to be available to everyone in the org. The top challenges are going to governance, and support, and then what you plan to do about it.
In practice, the real choice is:
1) Do you let makers create unrestricted, and you monitor, and promote high business value when found; and how will you support these new high value apps? This is the MS approach with Default being the core of the Maker Experience.
2) Lock everything down, including Default by making it a Managed Enviroment, and Cit Devs go through a light intake process to gain access to a shared environment.
1) This is the MS perspective. Organic growth, monitor, and detect high value, and govern with the CoE Toolkit. This will mean you need to ensure you have a robust Nurturing approach, as apps/flows will be created by makers either in Default, or from the 'Integrate' menu in any M365 collab tools. e.g. Sharepoint Apps are created by default in Default environment (can be changed).
You will need a full team to support this approach. The adoption guide has a team composition as support, and capacity of your team will be critcal with this approach. Basically you are reacting to what people do, and monitoring, and governing from that perspective.
2) Means you 'allow' people into a shared environment after passing through a gated intake. This lets you control the 'sprawl' of apps, and significantly reduce the one offs, orphaned apps, and a the support needs are a lot lower. Basically, if they want it bad enough to jump through some low, easy onboarding hoops, then it might have enough value to permit it, and you can also see if the request is something that has the potential to explode in use and therfore should really be directed to a 'pro' Power Platform team, to develop and support.
There's definitely a lot more to both points, however I tried to make it as simple as possible.
Overall, ask yourself/team what can you realistically handle for admin requests, and governance. What's your end state vision for Citizen Developers? What do you need to get there?
It's not about the technology, but about what kind of service/capabilities do you envision providing your business, where are you today, and where do you want to go, and how can the Power Platform help you do it. Then plan out your adoption strategy.
Also, don't confuse the Power Platform with the Collaboration tools like MS Forms or Sharepoint. They integrate, but the Collab tools are truly SaaS, and Power Apps, and Automate are more PaaS. You may find that all you really want to do is enable Cit Devs to use Collab tools, and NOT the Platform to reduce training, and support. There by leaving the Platform tools (Apps, Automate) for the 'Pro' teams only.
Good luck!
