I was in those lang team discussions, and I vividly remember talking through these proposals. We didn't decide that it was "not the direction ideal for Rust". We decided that it'd be a lot of additional work to specify a full solution for it that properly took into account things like cfg and path, that we weren't sure we had a consensus on wanting it yet, that the 2018 module system was already running late, and that if we tried to include this additional feature we would almost certainly have failed to ship the 2018 module system at all, which was a headline feature of the 2018 edition.
We recognized at the time that it'd be a substantial usability improvement to not need to write mod. But we also recognized the potential compatibility issues with stray files and with cfg and path directives. We would have needed a proposed solution that took all of that into account, and we didn't have one at hand.
I think we should still consider making a change like this. It'd be a substantial usability improvement.
As one example of a potential solution we could propose: We could handle the common cfg and path pattern for using different modules on different platforms by putting #![cfg(...)] inside the platform-specific modules. People could then write mod module { use target1_module::*; use target2_module::*; }, which would avoid having to duplicate the cfg directives as the modules for all but one target would be empty. (Using use target1_module as module; would require duplicate cfgs to avoid multiple conflicting use directives with the same as module.)
I think if we have a solution for the cfg/path problem, we can then treat other cases of "stray files" as something the compiler can mostly catch, one way or another.