Why do we use Oauth2 instead of Basic Auth in server to server communication using SSL?

If you use "username + password" for auth, sending the password on each request is a problem because authenticating the password is slow because the password is stored using a secure password storage method that is deliberately slow. So you want to use the password once to get a long computer-generated token and send that in the subsequent requests.

The high-entropy (long, computer generated) token can be stored in RAM only or can be stored hashed-once in a database, so validating it on every request is cheap.

It can also be stateless (e.g. HMAC of user id and timestamp, using a key available only to the server) but then invalidation requires storing a blacklist of invalidated tokens instead of whitelist of valid tokens, though hopefully the blacklist is smaller and if the tokens have reasonable lifetimes the blacklist shrinks as they expire.

If you send human-generated password in every request (naive basic auth) - stop. If you send long computer generated token in every request - it doesn't really matter how you format it in the HTTP request. A benefit of using the customary Authorization header is that a bunch of existing code already knows to not log it. Whether you format the token as Authorization: bearer <40char> or Authorization: basic base64(user_id:token or just first-half-of-token:second-half-of-token), it doesn't matter.

The full OAuth2 is too much code (that can contain bad security bugs) if you don't need it, so you can use something simpler (the simpler, the better). But you need to consider at least the cost per-request and how invalidation works.