For Windows users switching to Mac OS X, it's not really something they're used to doing. Instead of downloading an installer, clicking "Open" in the browser, and just following a guide leads to less issues with placing the application the correct place (Program Files), instead you get either a Zip file (so the bundle is in Downloads), an actual Installer (typically a .pkg), or a Disk Image which is often never unmounted. (I once saw a family member with 7 Flash Update disk images mounted)
As such, a lot of OS X users find themselves with a the Skype app in Desktop (inside a Disk Image), their Mail on the dock and some other app in Documents or Downloads. It requires that you organise it yourself.
Another way of saying it is that it lets you organize it yourself.
There will always be people who don't understand, or care to understand, how the system works. You can put in all the hand-holdy nonsense you want to cater to them and they'll still exist, but you'll be adding tedious and unnecessary hurdles in the workflow of people who do know what's going on.
To be fair, neither Program Data (which is effectively ALl Users AppData), nor AppData are endorsed as application installation locations by Microsoft. For a variety of reasons. Chrome started quite a trend, though for installations without admin privileges to install to AppData for convenience.
The big change was in the registry: HKEY_CLASSES_ROOT was no longer a direct shortcut to HKEY_LOCAL_MACHINE\SOFTWARE\Classes, but instead was a dynamically merged view of that key and HKEY_CURRENT_USER\Software\Classes.
This allowed you to register COM objects for the current user without requiring administrative privileges.
I and many other people were doing per-user installs long before Chrome existed.
This is especially useful for apps that auto-update. If you install in Program Files [(x86)] then you will pop a UAC prompt every time the app updates. If you install per-user it can be a silent update.
Also, Safari.app (e.g.) is not an executable -- it's essentially just a folder with special display characteristics in the Finder. Many app bundles contain several executables.
Heck even using the New... context window in Explorer is a joke.
On top of that, getting info about the application involves parsing .plist files, followed by parsing localization.
Similarly, yes, getting app info involves parsing files in a known location with a known format, how could that situation be better?
I’m not sure how often people fail to put applications where they go. Especially nowadays, where most applications ship as .dmg files that open to a giant arrow telling you to drag the app to Applications, and many nag you if they’re run while not there, and App Store solves this entirely by just putting them there.
Windows has various locations where apps are typically installed or dumped (Program files, Program files x86 , program data, app data...) where the particular executable in buried somewhere amongst everything else. Shortcuts to these and various other applications are scattered all over the place.
If you build such a simple approach to dropping applications into a single directory with big obvious icons, not only does it look clean to a user but it prevents naming duplication and allows your search tool to match to this directory first so you can esasily use Spotlight as a launcher.