Personally, I sometimes do this. I even sometimes decide on a per-accesskey base what files are needed. My main reason is to minimize load times. When an admin logs on, they might need JS and CSS for all the admin widgets which a normal user might not even see. So for a normal user, I can leave out all the CSS and JS for those widgets, saving bytes in the process. At the same time, restricting manual access to the files (like just entering the address) may help make attacks more difficult as an attacker has no source code, hence no way of knowing certain interfaces. So they will have to try out a lot more. Using AppSensor, you might be able to detect such behavior and react with a honey pot or aggressive honey pot.
The whole thing has to be implemented server-side, or you will not gain the security advantages. Of course, depending on your implementation, you might also allow for such files to be access either way (which you can do browser-side, take a look at module-loaders, like RequireJS), but personally, because of the security considerations, I would not do something like that.
@hipkiss91 I do not know if companies like Amazon do something like that. I can only speak for myself. My guess is that all resources (like CSS and JS files) are always accessible, even when the user is not logged in, but only loaded when needed.
If your browser needs certain files for the website to work, you have full access to the files. So you can open the resources (for example you could use your browser's developer menu) and copy everything to your local computer into a local file, prettify it, read it, understand it, reuse it, whatever.
All websites are put together by the browser from source. There is no binary distribution (yet), as long as you do not count plugins, like flash. Most websites do not use flash any more, so you get HTML, CSS and JS delivered to you as (minified) text files. When in Chrome on Windows, just hit F12 and go to the Sources tab to see all the stuff currently loaded.