Many of the features of such crates are making their way to the standard library, so things will definitely improve. Figuring out what is best has taken some time and Rust has not wanted to prematurely commit.
If anyone's interested in helping to shape the future of Rust's built-in error-handling story, there's an error handling project group that's been doing great work recently, e.g. the major effort to move the Error trait into libcore ( https://github.com/rust-lang/project-error-handling/issues/3 ) and stabilizing std::backtrace. You can follow along or get involved via the #project-error-handling channel on the Rust zulip: https://rust-lang.zulipchat.com/
I like what the error handling achieves, it is actually readable way to understand the divergent control flow paths (and probably majority of code is read more than written), but I do not enjoy writing the initial boilerplate, so that's good to hear.
Perhaps, but it's also much better than it was two years ago and there is work going on to make it better two years in the future.
A myriad of experimental prototypes (like the failure crate and its descendants) have been made, experimented with and then retired and looks like the progress is converging to these two complementary error handling crates (anyhow, thiserror, and a few mostly-compatible variants like eyre), and work going on to standardize some aspects of it so (parts of) these crates can be retired. There's also core::error that's bringing this to no-std environments.
So yeah, it definitely was not great on day 1 and there's been a lot of churn on error handling but it is going in the right direction.
It can be as verbose as you want. This guide as well as others suggests using concrete error types for libraries but anyhow "catch all" method for applications.
There is disadvantages for going "catch all" libraries as then you can't be sure you are catching all errors.