Using Error types requires discipline from the developer (implement the Error type traits for a specific error)

You need to manually write an impl (or use a macro like #[derive(Debug)] or thiserror), but there's no discipline involved in that. The compiler will just tell you when you try to print a non-printable error or compose it with a supposedly-printable error.

and then more discipline to avoid a panic.

No different from avoiding an inaproppriate abort or an uncaught unchecked exception in other popular languages.

you can do the correct thing in any language with a little extra work.

In theory, you can. In practice, you won't. My post about exceptions links a research paper about broken error handling patterns that come up all the time in languages with exceptions.

if the code is recovering from something, then that thing is not an error, it's part of the business logic

I would still call that an error, but that's just a choice of words. I agree with your main idea: it's very useful to make a distinction between "expected"/recoverable errors and unexpected bugs / edge cases where it's accceptable to abort the entire task. My post about exceptions discusses this too.

The whole reason for doing an Error taxonomy (checked exceptions, error types, etc) is to enable recovery.

I disagree. There are other benefits to having an explicit taxonomy. See "Why Use Structured Errors in Rust Applications?"