That was the point. The paragraph is talking about how errors only show up in some configurations, leading to “works for me” behavior for some of the devs. When you can get away with cfg!, you are more confident that it will at least compile regardless of the config being checked.
It will remove it, but not until after resolving symbols. If the branch-never-taken references a missing library then this will still error, which is the problem for a feature flag.
My experience with this is the other way around, especially if you have crates tied to that feature.
The cfg! is a marco that compiles to true/false, so whatever is inside of the if guard needs to compile regardless.
E.g.:
Cargo.toml
And in code: This will fail if you compile without `my_feature`.