While I agree with Justin Tadlock on a lot of things, I strongly disagree with him on this.
The reason parent/child themes exist is that there’s a lot of common functionality used across websites. Instead of re-inventing the wheel every time, it’s better to build from a solid base that has been tested by hundreds of developers and used on tens of thousands of websites.
From a security perspective, as long as you know your parent theme is secure (StudioPress hires Mark Jaquith, lead developer of WordPress and lead of the security team, to review it), then you only have to be concerned with the 10-20% of custom code you write in your child theme. It drastically reduces security risks.
From a cost perspective, a developer like me can reduce development time by 4-5x by using a theme framework like Genesis. I’m able to charge $2,500 for a website because of all the time Genesis saves me in development. When I build a theme from scratch (whether to be standalone or serve as its own parent theme), the minimum cost rises to $10,000 and is typically in the $20-50k range.
From a developer perspective, using a theme framework developed by several top developers and used by hundreds of other developers ensures that every small feature has had more time dedicated to solving it the right way than you would ever have to spend on it. For a typical website we can’t justify spending more than an hour setting up breadcrumbs, but I can guarantee over 50 hours of development time has gone it in Genesis. And due to Genesis’ implementation, it takes me less than a minute to implement breadcrumbs in whatever way we want.
The only time I recommend developing a standalone theme or a new parent theme for a client is if they’re looking to build their own base theme which can then be deployed across dozens of sites, with each site having its own customizations (through a child theme). And even then, it can be more cost effective to use a parent theme like Genesis and have your “base” theme be a child theme. You can make minor CSS customizations using Jetpack’s Edit CSS feature (or find a plugin that does the same thing), and you can make functionality customizations through a site-specific core functionality plugin.
I encourage you to find the right solution to your problem. You might need a child theme, or you might need a parent theme developed. But one of your considerations should be cost, because by not leveraging a parent theme / framework you’ll increase required development time, and therefore cost.
My own opinion of the differences between a parent theme and a framework also differs with Justin. He says they are not the same thing. I say they can be the same thing.
1. A parent theme is a theme which is extended through a child theme. The child theme is the site-specific customizations, while the parent theme contains network-wide code or generalized code useful on many sites.
2. A theme framework is a strong base from which to build your theme.
When they are combined, you have a solid base that is continually being improved. When your framework is not your parent theme (ex: underscores), you’re “frozen in time”, stuck with the code it had when you originally forked it. If new improvements are made to the framework, you don’t receive them. For this reason, non-parent theme frameworks are typically really lean so they don’t benefit much from future updates.