The borrow checker doesn't determine whether a program is valid or not (if by valid you mean safe). It can be proven that doing so is actually imposible. What it does is that it attempts to prove that your program is valid, but will fail unless the proof is trivial, and it never tries to prove that your program is invalid.
The point is that you, the programmer, has intelligence and creativity and can prove that some programs are valid, while the borrow checker wouldn't be able to. So the set of rules you'd follow might be different. This is true, in theory, of many programmers in C++ for example, with the drawback that you might have made a mistake in your proof to yourself.
I'd claim that the Rust philosophy is "the general case is undecidable, but if we restrict the scope to 90% of the cases, we can automate the checks and give you an escape hatch for the remaining 10%". I personally appreciate that approach because the remaining 10% of cases are actually uncommon enough in what I do that I don't have to even think about the problem most of the time.
But that's not actually true. It's very common have to have a program that is valid and won't pass the borrow checker. You need to adjust the way you program to generate programs the borrow checker will approve of, and then the 10% is when it's hard or impossible to make that adjustment.
It's fine, it's just that it is more restrictive than the philosophy claims. It's still a good approach.
The point is that you, the programmer, has intelligence and creativity and can prove that some programs are valid, while the borrow checker wouldn't be able to. So the set of rules you'd follow might be different. This is true, in theory, of many programmers in C++ for example, with the drawback that you might have made a mistake in your proof to yourself.