But the server security is the primary security, because it's the one with the resources (in the money analogy it's the bank).
So yes, we do want to secure the client, but if the attacker has enough control of your computer to get your cookies then it's already game over. Like I said you can have time bounded CSRF tokens (be they cookies or whatever else, URL encoded, etc who cares) to prevent replay attacks. But at the end of the day if an attacker can get your cookies in real time you're done for, it's game over already. If they want to do a man in the middle attack (i.e. click on a fake "proxy" URL) then having the "secure" flag should be enough. If the server checks the cookie against the client's IP address, time, HMAC, other auth attributes, will then prevent the attack. If they attacker takes control of your end device, you've already lost.
I, the article and most comments here quite explicitly talked about server security via Auth and csrf protections.
None of this has anything to do with browser security, such as stealing csrf tokens (which tend to be stored as hidden fields on elements in the html, not cookies). MOREOVER, Sec-Fetch-Site obviates the need for csrf tokens.
"It is important to note that Fetch Metadata headers should be implemented as an additional layer defense in depth concept. This attribute should not replace a [sic] CSRF tokens (or equivalent framework protections)." -- OWASP; https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re...