No, the separation has nothing to do whether errors are handled or not.

If error handling is mandated by the compiler (e.g. checked exceptions), there will be no unhandled errors since the compiler will simply refuse to compile your code until you handle these errors.

Whether you handle these errors near the happy path or in a different section of the code is an orthogonal concern.

I don't see the value in a clean happy path and a hidden error path.

Go already has unchecked exceptions. It's called "panic".

So either developers are already abusing it, in which case go's current error-handling approach is no better than the one proposed according to your metric. Or developers have access to it but aren't abusing it, in which case there's no reason to expect they'd abuse it in a system where doing it the right way is even easier than it is today.

In my experience, users already do experience stack traces as it's embarrassingly easy to accidentally operate on a nil pointer.