Q:

Is CSRF still a relevant attack vector? 

CSRF was part of older OWASP TOP 10 lists but has been retired "as many frameworks include CSRF defenses, it was found in only 5% of applications". 
But even without frameworks doing CSRF defense, I've got the feeling that modern browsers already mitigate the problem.  Cookies and headers needed for authentication are not sent by default in cross site requests. 
For instance, if an XMLHttpRequest should send cookies, the withcredentials-flag has to be set.  And even then, the target server has to implement a CORS header for the request to be successful.  At least in Chrome. 
So I now wonder, which browsers already implement those counter measures and if they are enough as defense or if we still have to implement CSRF mitigations in our applications. 

A:

... if an XMLHttpRequest should send cookies, the withcredentials-flag has to be set.  And even then, the target server has to implement a CORS header for the request to be successful. ...   which browsers already implement those counter measures and if they are enough as defense or if we still have to implement CSRF mitigations in our applications. 

CORS for XHR is not a new mitigation and it even isn't a mitigation against previously working attacks at all.  When XMLHttpRequest was designed no cross-origin requests were possible at all.  And only with the introduction of CORS this restrictions was changed and replaced with cross-origin requests controlled by a CORS policy.  Thus, all the old browsers which did not implement CORS were not affected by CSRF via XHR in the first place. 
Nevertheless, CSRF is still a problem and can still be used the same way as it could in the past.  XHR is not needed as a vector for CSRF attacks at all and it did not work in the past anyway.  Instead cross-site image includes, cross-site form submits or similar can be used, which still automatically send the necessary credentials and cookies cross-site.   The new samesite attribute for cookies can be used to prevent this but it has to be explicitly set by the application and not all browsers support it yet. 
Therefore proper CSRF protection is still needed today.   
What happens if CSRF protection is not properly implement can be seen for example by recent news like Hackers Launching Massive Cyber Attack Against 800,000 DrayTek Routers by Exploiting zero-day Vulnerability. 

A:

Cookies and headers needed for authentication are not sent by default in cross site requests. 

That is not correct.  If a user clicks a link or post a form on evil.com to example.com, cookies will be included.  The user doesn't even have to click the link or submit button, it can be automated  with a script. 

For instance, if an XMLHttpRequest should send cookies, the withcredentials-flag has to be set.  And even then, the target server has to implement a CORS header for the request to be successful.  

Yeah, sure.  But why would an attacker need XHR when you can just use an old fashioned form? 

So I now wonder, which browsers already implement those counter measures and if they are enough as defense or if we still have to implement CSRF mitigations in our applications. 

Browsers do not implement any automatic counter measures, so you still need to do it.  Vulnerable sites will continue to be vulnerable no matter how modern browsers we use. 
In one way you are right, though.  Modern API:s are often designed in ways that gives them at least some CSRF protection by default.  This happens for instance if you do authentication with a authorization header instead of cookies, or if you only accept POST requests with a JSON body.