Theoretically, you are right: the web could have been designed in such a way that browsers could detect and prevent these attacks. However, it was not designed that way, and there is no trivial fix that a browser can apply that doesn't break large number of existing websites.
One simplest example: By default, disallow cross-site requests at all?
A "cross-site request", in the context of CSRF, could be as simple as "an <img>
tag referencing an image hosted on another domain". Preventing such requests would break so many websites that the browser would simply be considered broken by all its users.
It is the browser which must stop making unauthorized requests.
The request is only "unauthorised" in the sense that a particular user didn't request it. This, on the face of it, is a more promising approach: allow the request to be made, but don't let it be authenticated as the action of any particular user.
The problem here is that the vast majority of authentication used by web applications is not actually visible to the browser as authentication at all; at most, the browser knows that the server has requested that one or more opaque strings ("cookies") be returned to it on the next request.
So, browsers would need to stop sending all cookies in requests which are "cross-site", in the sense of CSRF - when requesting images and other assets for use in an HTML page served from a different domain; when submitting forms targetting a different domain; etc.
why should different domains (this should mean: different parties) want to talk to themselves through the user?
One obvious use case is the tracking systems used by analytics and advertising services - you might argue we'd be better off if browsers did just break them, but since the world's most popular web browser right now is developed by a company that makes a large portion of its revenue from such services, this is unlikely to happen.
Sometimes, communicating between services in the browser actually enhances the user's privacy - if the only communication that can happen is on the server, both servers have to know and discuss the user's identity.
If the web had evolved with these security considerations in mind, the safe uses of CSRF-like behaviour would be implemented by other means; but even if new protocols and APIs are invented now, it is very hard to change the default behaviour of browsers without breaking a large amount of existing content.
As such, features to protect against it, however standardised, will always be opt in, so require some work by the developer of the application, to say "I'm not relying on feature X, so please disable it so it can't be abused". Things like Content Security Policy headers, and the HttpOnly and SameSite cookie options, are such opt-ins. Things like CSRF tokens in forms are ways of not relying on the user to have an up to date browser that implements all the necessary protections.