At Nimbusec we use SameSite:strict to prevent CSRF attacks.
While CSRF Token work best in preventing CSRF attacks, the implementation of these tokens is not a pleasant work, and can lead to errors if a developer forgets to implement them for a new form.
With the Cookie attribute SameSite:strict, the developer does not have to worry about CSRF attacks anymore when adding a new form. The CSRF protection just works.

Preventing CSRF with the same-site cookie attribute
Cookies are typically sent to third parties in cross origin requests. This can be abused to do CSRF attacks. Recently a new cookie attribute was proposed to disable third-party usage for some cookies, to prevent CSRF attacks. This post will describe the same-site cookie attribute and how it helps ag…

SameSite:strictIn our opinion, CSRF should not be a problem a website owner has to fix. CSRF should be fixed by the browser, because the whole WWW is affected by it.
Disadvantages of CSRF token (on a developers point of view):
* needs extra code for implementation.
* if using a library, this library must be updated and maintained.
* needs to be added to each form. May be added to only 4 of 5 forms. The fifth form would then be vulnerable.
* adds more boilerplate to the code
* frustrates the developer

Disadvantages of SameSite:strict (on a customers point of view):
* is not supported in Internet Explorer 😵 https://developer.mozilla.org/de/docs/Web/HTTP/Headers/Set-Cookie/SameSite#Browser_compatibility

UPDATE 02/01/21
* SameSite:strict does not protect against cross-origin, same-site attacks. For example, subdomains are cross-origin but same-site. This means that (maliciously crafted) requests from subdomains carry all the relevant cookie information regardless of the value of their SameSite attribute. An XSS vulnerability on a subdomain, or a subdomain takeover is enough to render a Website vulnerable.
Thanks to @jub0bs to pointing us to the issue with this blog post.