No matter which organization is chosen, it will make some things easier and some things more difficult.
Organizing files by types, the Unix way (into bin, man, lib/python, …), makes it easier to use files. If you want to run a command, you know where to find it, no matter which package provides it. If you want to search through documentation, it's all in one place. If some program provides a Vim syntax highlighting module, a zsh completion function, or Python bindings, the relevant file will be in a place where vim/zsh/python can find it.
Unix also organizes files by usage patterns. Configuration files go in /etc, files that don't change in normal operation go in /usr, and files that change automatically go in /var. User data goes under /home. This is very useful for configuration management (manage what's in /etc plus the list of installed packages). It's also useful to define backup strategies: what's in /etc and /home is critically important, whereas what's in /usr can easily be downloaded again.
The main cost of the Unix way is that installing a piece of software is spread across many directories. However, modern unix systems have package managers anyway; managing files in many directories is by far not the most complex thing they do (tracking dependencies is very useful and harder).
Contrast that with Windows. Windows started out with no package management, and each application created its own directory somewhere. All files would normally be inside that directory: programs, static data, user data, … Except sometimes for libraries which programs would drop into a common system directory with no regard for conflicts (“DLL hell”). Over time, Windows became multi-user, requiring the separation of user directories from system directories. Windows also created a central place for configuration files (Unix's /etc) and some system data (Unix's /var), the registry. This is more of a historical artifact largely due to the lack of package management and the early history as a single-user system. The Windows approach has a lot of limitations: it doesn't let software packages interact easily. For example, most installed software doesn't end up on the default command search path, so it interacts badly with any form of scripting. Installers typically provide a menu icon as a special case — dropped into a separate system directory (à la Unix!).
A limitation of the Unix approach is that it doesn't easily permit the coexistence of multiple versions of a package, which is especially problematic while the package is being upgraded. A way to get the best of both worlds would be to unpack each package in its own directory (an /opt structure), and create forests of symbolic links from package directories to a /usr structure. This is what software like stow does.
In summary, the Unix approach makes it easier to use files, to manage files, and to allow packages to interact; it requires package management software, but that's desirable anyway. The Windows approach makes it easier to manage packages manually, but has to veer towards the Unix model to get useful functionality.
