I could have toned this down, but I really hate code residing in the Concrete CMS /application/ directory. When I work on a  Concrete CMS site, I implement everything in packages, including the theme and any application specific block templates.

When code absolutely has to be placed in /application/ because that is the only place it can work, then I make it no more than a minimal wrapper for calling back to the actual code in a package. Don't let an exception to the rule become the thin end of the wedge.

This enables developers to easily move code between staging, production and each developer's development sites and avoid discontinuities between them.

If you like to work with Git, a Package is a natural item to manage as a Git project. With everything in packages, then for most web site projects any global Git across the whole project is unnecessary.

Keep theme and application code separate

A theme should be a generic package for a design. Application specific code should be in one or more other packages. If a theme developer is creating some simple generic blocks, they can go in the theme or in a block specific package. As soon as a block begins to provide application specific functionality, it is better in an application specific package.

When in trouble, swapping a site theme or marketplace theme for Atomik, or applying the site theme to a set of standard content, enables half of the problem to be quickly eliminated.

Use standard theme area and template names

Conforming to the standard names for areas and templates is a prerequisite for the above. Without standard names, swapping a theme will lead to zombie content.

For site owners

If a developer knows what they are doing, packages are a benefit to them and to you. If a developer doesn't know how to work in packages, should they really be working for you?