While it is often useful to understand what the motivating goal was for the design of a new system like secure enclaves and what the practitioners primary concerns are, in the end it doesn't actually matter what the designers intender. Rather, what matters is what it actually does and provides. As long as the new functionality can be used for other useful purposes that are still within the design goals and parameters, it would be useful. Tool doesn't care what the creator intended - it's whether the tool is useful for whatever purpose it can be used for.

Thus I find most analysis and comments like this, based only on motivation and incentives, very lacking.

Add to that, to be more specific to this particular topic, secure enclaves are designed not only for DRM but for many other critical applications (that are actually far more important than DRM and are/were the key motivating use cases) - it, or the general concept, is the basis of the security guarantee for iPhone's fingerprint or face ID, or the confidentiality of the key materials in various end-to-end encryption, which allows things like the-phone-as-a-security-key.

The intention is quite important for estimating which workflows would be easy and what a response could be, given an atypical use case. (E.g. if this has a backdoor, when would it be used?)

Given the audience of this site....who do you think writes those apps?

True, but I'm assuming that this is all moving towards enclaves being more standard and cross platform.