I believe that your argument is implied in the article. Errors that are expected at runtime must be handled (preferably in the application code), instead of unwrapping it. If the thread does panic due to an unwrap (even without crashing the main thread), it's a logical error in the library that must be resolved before the public/production release.
There are cases where unwrap may be necessary even within a library. Burntsushi's own regex crate has an example of this. You get a Result when you construct a regex - which is reasonable if the regex is parsed at runtime. But I don't see any reason to not use unwrap, if the expression is a static string within the library source.
There are cases where unwrap may be necessary even within a library. Burntsushi's own regex crate has an example of this. You get a Result when you construct a regex - which is reasonable if the regex is parsed at runtime. But I don't see any reason to not use unwrap, if the expression is a static string within the library source.