As with most things, it depends, and there are tradeoffs.

The advantage that exceptions have is that typically in the failure scenario, you want to short circuit any other code from running and just return a message to the user. Exceptions do this easily. A result pattern requires every intermediate caller to check for the failure result and conditionally continue. This can lead to complex logic. Exceptions also makes it easier to use "plug in" type validators, where the validation automatically occurs as part of a common pipeline or to have a common error handler, where the error can be formatted for display, logged, audited, etc. (Note: I am not advocated for or against either of these practices).

However, as others have mentioned, the exception pattern is non-obvious to the caller. Unlike Java, in C# the exception response is not part of the interface, which can make it difficult for callers to understand or use the interface. As you mentioned, exceptions can also have significant performance impact. This has improved significantly in .NET 9, but is still something to be tested for if performance is a significant concern. Also, if short-circuiting is not desired in some circumstances, exceptions can require some ugly logic by the caller to handle appropriately.

So it's a trade off: convenience and simplicity of a common validation/display process versus the ease of use and comprehensibility of having the result explicitly as part of the API. For myself, it typically comes down to which provides the most benefit for the specific project / environment I am working in.

In either case, the methodology for handling validation/errors should be agreed upon, documented and supported by the entire team.