I don't think we want this as default enabled security wise.
It opens the API to scripted attacks easily. If your app wants to support this it can easily specify that header in the constructor of the controller.

Thanks for you thoughts. But I don't agree and I try to show you why:

The corsAllowedHeaders variable is only used by the function preflightedCors.
The sole purpose of this function is to make it easier to add a preflighted cors response.
It does not change the behavior or security of the underlying API.

I only added this header to the OCSController for OCS API calls, that requires this header to be present.
In my understanding, if you want to use this helper function with the OCS API, the OCS-APIRequest header must always be added. Otherwise this helper is useless, as it does not help with preflight Cors requests.
I don't see, why the other default headers Authorization, Content-Type, Accept are present and the OCS-APIRequest should imply a security risk.

It opens the API to scripted attacks easily.

I don't agree on this. The API is open to scripted attacks independent of this header parameter.
If the API is public, it can be attacked by scripts.
The only one caring for this header are the browsers.

So in my opinion this is kind of security by obscurity.
If a developer opens up the API (unknowingly) and tests it with a browser, the request will fail.
But not due to some good security measurements, but only because the browser refuses to call the API.
Any other script will happily access the API, as this header does not prevent it in any way.