I get why you think it's silly. I'm pretty sure I thought that too when I first encountered it. But I think it makes sense and there is actually a way to support more than one but not wildcard. Multiple origin domains are supported by using the pre-flight request to change the one domain returned based on what is in the pre-flight request.

I don't know what the actual reason was, but I would guess the design decision was made so the multiple domains use case would be infinitely scalable. Otherwise you would run into header length limitations. Imagine trying to fit 10,000 domains into the header! Eventually you'd need something like this implementation anyways.

although browsers only accept a single origin domain or wildcard as cors header, the server can trivially handle the multi domain use case. on preflight request, check the location header in the request, and if it belongs to a defined whitelist, set the cors header on the response to that domain or subdomain. I don't know the why, but I can imagine that since there is a reasonable work around, browser implementers perhaps kept things simple and never bothered adding support for a list of specific domains.

It's inconvenient for sure but I've never dug deep into this the issue.

My guess is that it's related to subdomains not guaranteeing to be from the same origin.

The result is that people run into errors, Google them, copy paste the top SO result which advices to allow *

Doesn't seem ideal

Good question... most likely an oversight, or maybe it's to discourage lazy server operators from packing every response's headers with 50 origins.