I totally understand the appeal for sanity checks, guards, etc.
What I’m saying is that you should generally aim at having the least complex type possible, so if you only care about the presence or absence of a value and not about the error, then use an option<'a> instead of a result<'a, 'error>, but if your code can only work with the presence of this value, then just use 'a and raise an exception when it’s not there. Otherwise, what’s the point of carrying around the error if you never actually read it?
To me, results are great when you do want to take into consideration both ok and error cases, by using switch you get exhaustiveness checks (I try to pattern match every case of the error variant for example), this way, the day you add a new error case, you get helped by the compiler. If you start using results and just throw the error information at the beginning of each function with sanity checks, you lose this exhaustiveness check and don’t really use your result type. I know I got bitten by this quite a few times using let* in ocaml.
It makes you focus on the happy path, if it’s used only in a few places it’s ok, but if you never care about the error cases, it can become a smell.
One more time, I’m not saying this makes early returns useless but it should make you think about how pervasive and automatic their usage should be. And a good language should take this into consideration.