¹ Server components don't have to be async, and client components might support async in the future. So, the presence/absence of async doesn't indicate component type.
² A module without "use client" could be imported into either environment, which would be what actually changes its type.
³ Using or not using client APIs like hooks and event handlers doesn't change a component type. However, importing APIs into an environment that doesn't support them will cause an error.
⁴ “use server” currently marks server functions that can be called from the client through an internal endpoint. It's the first use of a general-purpose directive. As of today, it doesn’t mark a server environment entry point.
⁵ Server Components are not the "default" because components do not have an inherent type until they are imported and used.
In Next.js, the framework starts route entry points in the server environment and imports developer-defined route segments into the server environment. So, you could argue that Server Components are effectively the default. But, it's the act of importing and using, not an innate property of a component when defined.
I strongly disagree with this. I introduced coupling of components with data-fetching at Google in 2013ish, and it has proven extraordinarily successful. You probably used this today!
Not leaking how to fetch data to the composing app is really a game-changer for composability. The nuance is that you do want to structure your app such that data-fetching is limited to a subset of components.
The Twitter UI is a good example. Just drop the "Trending" component on the page. Why should the page know how to fetch the data for that and then pass it to that component. Let the component do it!