the backend API server was reflecting the Origin header from a credentialed request in the Access-Control-Allow-Origin header
I assume by this you meant that it's reflecting arbitrary Origins, not just trusted ones? Assuming that the API uses cookies (or HTTP basic/digest auth, which is rare), then this is absolutely a problem.
I don't believe there is a CORS issue here as for most of the endpoints there were preflight requests performed
Do those preflights actually block the request if it comes from an untrusted origin? Usually if a server is reflecting arbitrary origins in ACAO, it does that for both preflight and non-preflight requests, and usually if it supports preflights at all, it always returns the same set of CORS permissions (aside from ACAO) in all preflight responses (or at least all that have allowed origins).
Preflights by themselves don't inherently prevent CORS issues. They're a "checkpoint" of a sort - a place where security controls can be enforced - but that depends on them being configured correctly, and "reflect the origin in ACAO, plus ACAC: true" is definitely not configured correctly.
Does this mean that an attacker could cause a victim to login to this site by issuing an authentication request from their own attacking server
Sounds like you're describing "login CSRF", which most sites are vulnerable to (it's possible to put at least some protections in place against it, but almost nobody does). How big of a deal it is depends on things like how likely the user is to notice being signed into the wrong account, and how big the risk of the user sending sensitive data to the wrong account would be, and so on. Of course, it's also possible it won't even work, because...
... before receiving an Authorization token
If by "Authorization token" you mean "Bearer token", sent in the HTTP request header "Authorization"... then all of this is irrelevant. CORS misconfiguration, like CSRF, is only really a threat when the user is authenticated via something that the browser will send automatically (cookies or HTTP basic/digest auth). Bearer auth tokens are not sent automatically, so for them there is basically no risk of either CSRF (even login CSRF, because the returned token won't be stored in the relevant site) or CORS misconfig (because without knowing the header, it can't be set by the attacker, so the attacker's requests will be unauthenticated, there's no way to steal data from the user's account or take actions on the user's behalf).
It's the important details of how your auth works, like whether you use cookies or Bearer tokens, that really matter for questions like this!
Is there any difference or security considerations if the ACAO header is reflecting the Origin header for credentialed requests as opposed to having it set to a wildcard (*)?
Leaving aside the possibility of Bearer tokens, yes there absolutely is! Combining ACAO: * and ACAC: true is a violation of the spec and the client is required to treat it as though ACAC was false / absent. Obviously that's not the case for ACAO with an actual origin, or else ACAC would never have a meaning at all. Because ACAO: * is always treated as uncredentialed, it it can't be used to steal private information from the server. This doesn't prevent CSRF, of course, but usually you don't need XHR/fetch to do CSRF at all.
