I’m not even the original designer of the approach — I’m sure she or he had their own set of logical arguments.
For me and the projects I have been working on, it comes down to a few things:
1) If you are distributing on more than one market (Google Play, Android App Store, OUYA, etc) you will need multiple Android projects with different selection routines for the Resources folder.
2) Your Resources folder contains files for Android, iPhone, WinPhone, OUYA, BlackBerry, Linux, Win32 … this means multiple GL texture formats, resolutions, music formats and so on.
3) If you are using tools like Cocos Builder or TexturePacker you’ll want the ability to filter out project or uncompiled file types.
I’m sure if we really sat down and mapped it all out we’d find a bunch more reasons you want Resources to be a central repository and the projects to be filtered copies.