To be absolutely clear: the only public API for instantiating components is from within templates. This is intentional.
I realize that experienced Ember devs are accustomed to the old view hierarchy model, and so they tend to reach for that when they hit a blocker. But that model doesn’t actually exist anymore, and in the places where it still works, you’re actually using backward-compatibility shims provided by Glimmer that incur performance cost.
If you find something that’s not possible to wire up correctly in a template, that’s a bug we need to solve. It sounds like the only gap mentioned in this thread so far is the need for a splat operator, which is something I want too, and I’m sure we can add without much difficulty. Another relevant discussion is the contextual component lookup RFC.
Liquid Fire has the same issue with modals that you’re describing, but I’m convinced that’s actually because it’s not a great API in the first place. Any time people are trying to describe how to render a component, but they’re not doing so from a template, you’re forced to reimplement a bunch of nice things that templates do automatically. My plan for liquid-fire is to deprecate the existing modals and instead make it easy to compose liquid-fire plus ember-wormhole, so that addons like ember-modal-dialog can easily animate.