From the advantages of this approach, I can notice that you do not have to manually set the authorization header, because the browser itself will attach a cookie with the token to the request.
It will also be easier to handle the expiration of the access token, because with each request, both tokens (both access and refresh) will be sent to the server, and in case of expiration, you can quickly update the tokens.
What are the disadvantages of this approach that I don't notice?
If you can use a cookie-based session, then stick to that. If you use HTTP-only, same-site, secure cookies then your solution will be more secure than a token-based one (you will be protected from XSS attacks). If you can use cookies, don't even bother with access and refresh tokens, just use sessions.
That said, there are situations where you don't control the APIs that you call. These APIs are usually third-party APIs and require access tokens to call them. In those cases you can't keep the token in a cookie, as you don't control cookies from the API's domain.
If you still want to keep tokens in cookies, even when these are not your tokens, then you would have to introduce some middleware that will be responsible for extracting tokens from cookies and making requests to the APIs directly with tokens. This adds a bit of a complexity to your solution, as you need some additional software, but it keeps the tokens away from the browser.