One example: Alice configures CORS on https://alice.com to allow https://example.com with request headers Authorization. However, in her client (running on https://example.com), she also sends some Foo request header: fetch('//alice.com', {headers: {'Foo': 'Foo'}}). Obviously, CORS preflight then fails because the Foo header isn't allowed in Alice's CORS config. But most middleware libraries, according to the resource-processing model (as I understand it) would omit the ACAO header altogether from the response. When debugging the CORS error in the browser, Alice would be confronted with an error message like

Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

which is true but a bit misleading about the actual reason why the server didn't respond with the required CORS headers (i.e. that request header Foo is not allowed).

In my experience, many CORS-related questions asked on Stack Overflow stem from this design decision. But that's not inevitable. A CORS middleware library could reply with ACAO: https://example.com and no ACAH header (or simply ACAH: authorization). Then the browser's error message would be more useful for debugging purposes:

Request header field Foo is not allowed by Access-Control-Allow-Headers in preflight response.

Since nothing much happens during preflight on the server side (as the CORS middleware should handle the preflight request rather than passing it on to the next handler in the chain), I'm wondering whether worrying about side-channel attacks during preflight is justified. Do you know of such attacks? I know the Fetch standard mentions that possibility:

Any other kind of HTTP response is not successful and will either end up not being shared or fail the CORS-preflight request. Be aware that any work the server performs might nonetheless leak through side channels, such as timing. If server developers wish to denote this explicitly, the 403 status can be used, coupled with omitting the relevant headers.

But has it ever been an issue in practice?

Yes. I think this passage deserves at least some clarification:

Be aware that any work the server performs might nonetheless leak through side channels, such as timing. If server developers wish to denote this explicitly, the 403 status can be used, coupled with omitting the relevant headers.

In particular, I'm not sure myself what "denote this" refers to...