OAuth is an internet standard and you can write a client in literally C if you in any way know HTTP, and I do mean YOU can do it.
I haven't been very deep in the .net ecosystem but haven't had any issues implementing an api woth auth and rate limiting etc using dotnet and nothing Microsoft licensed.
For a small/solo team, which is the audience under consideration, they probably want to spend their time on their core product and not reimplementing oauth.
I'm not saying they need to reimplment it. My argument is that it is absurdly simple in any batteries included stack to do OAuth even without specific support, not that .NET doesn't have a multitude of open source implementations that isn't what OP mentioned.
It's an API call to an external provider and like 2 endpoints on your side. If this doesn't take you at most a few hours to implement yourself then I don't think you should be relying on a library in the first place, go implement it in your spare time. Then you can use the library with your new found understanding of how absurdly easy it is.
Maybe you will learn about implicit flows and how OIDC would allow you to validate JWTs and never have to write a single line of server code to deal with OAuth.
Maybe you will learn about SCIM[1] and all the interesting stuff related to auth that you never bothered learning because the library does that. Maybe the business that is paying you would prefer SCIM + SAML/OIDC but you could not even begin to discuss is because your library doesn't do that.
I haven't been very deep in the .net ecosystem but haven't had any issues implementing an api woth auth and rate limiting etc using dotnet and nothing Microsoft licensed.