Your recommendation of some modules as best practice for all sites is not necessarily accurate. For instance CCK and Views are definitely recommended, but a simpler site very well may not require them and adding them when unneeded adds to the memory footprint of Drupal and also adds more modules to care for security/updates (never add any modules you do not actually need). Some of the other mentioned modules may certainly be recommended as needed as well, but not as “best practice for all sites” per se (and some are actually not recommended at all). TinyMCE module should definitely not be recommended, as it is fully deprecated in favor of the Wysiwyg API (which is the future handler of all Wysiwyg functionality in Drupal… it is a single unified module for plugging in and configuring a wide variety of Wysiwyg editors). Various modules likely to be recommended include Filefield, ImageAPI, ImageField, ImageCache, Voting API, Administration Menu, etc.

One does not need to have strong skills in Javascript/jQuery to work with or develop for Drupal. In fact quite complex sites can be created in Drupal with little to no coding beyond HTML and CSS, and a slight touch of the most basic PHP (e.g. simply copying and pasting the dynamic variables in the template files if any adjustments are needed). If developing modules yourself, intermediate or better PHP experience is recommended, and of course if you need to create custom jQuery features and effects you’d need to understand jQuery.

Best practice is to always put all contributed modules into sites/all/modules and all contributed themes in sites/all/themes, regardless of whether you initially use the multi-site capabilities or not. Placing them only at the path you mentioned (sites/all) is not correct. If you do have a multi-site you can place modules and themes into that site’s own sites/sitename.com/modules (and themes) directories to make them available only to that site.

Regarding scalability… you didn’t quite accurately portray the information you acquired from the source article. For instance the site does not say CCK is bad for high traffic sites – it recommends avoiding or reducing the practice of using shared fields in CCK (the reason being that it causes fields to split into their own tables, therefore causing extra join queries when calling the data up, which can be bad for performance [this only applies to logged in users, not regular visitors, which are heavily cached]). CCK is used on huge Drupal sites such as those by Sony, Symantec, MTV UK, and others. Also the part regarding theming being part of the “data architecture” wasn’t accurately represented (the referenced article says “Drupal’s architecture” which is completely different).

Anyhow I just wanted to help clarify these points for those who may read this in the future. Thanks for your post