I think if elements like threads, security-policy, containers etc exist outside of a server-group (or one if it's children) it should either be because:
1) Whatever the element describes is intrinsically scoped to the domain (e.g. domain-configuration)
or
2) That element serves as a common confiugration that can be referenced by a (child of) server-group, to avoid having to repeat things across multiple server-group elements.
The latter can save a lot of boilerplate in a complex domain, but it's not intuitive. Perhaps such elements should be enclosed in a container element (e.g. "templates") that explains their usage. (I don't like "templates", just haven't thought of anything else.)
I definitely don't think that the presence of something like web-container at the domain level should imply that every server runs a web container.
If we follow David's thinking that a server's capabilities are determined by what the end user deployments required, then the fixed profile notion largely goes away. Then there could be a 3rd usage for things like threads, security-policy, containers, etc:
3) as the default configuration for X if it turns out that deployments in a server-group introduce a requirement for X.