Time and time again the debate about "what is content" and "what is configuration" comes up. I think not often enough we talk about it in words but not in the intentions of what you are building. This article is just about content, because everything else is just code.
First of all, what is "Content", really? It recently has become crystal clear to me:
Content is something that can (and should) be safely edited in real-time on your live website or application.
More and more I hear about people wanting "content staging" so they can move content from one server to another, setting up Deploy.module just to move some nodes around, and "Exported Content" going into Features modules so you can "deploy" content, it drives me a little mad.
It frustrates me that Drupal was supposed to be built to handle live content editing, yet, more often than not the content editing experience, for your specific website is an afterthought.
Drupal is a Content Management (System) Framework!
Drupal is a framework for building personalized content management systems. Every Drupal site is it's own CMS. Each one is slightly different, (hopefully) tuned to support its intended long-term users.
You can edit content in Drupal! Built-in! Even if you make a mistake, click Edit again and fix it.
If your nodes can't be edited by a novice because you might break the HTML, then install WYSIWYG and proper Filter Formats and you've solved the problem. If you can't let customers edit your nodes because you filled your nodes with custom HTML, then you are doing it wrong!
Do you need someone to approve things on a staging server before they go live? Why not install Workbench Moderation module so you can track revisions and create new, drafts for review before publication?
You don't need elaborate remote content distribution unless you have an actual reason. If you want Content Staging, what you really mean is you want Workbench Moderation.
Make it your own.
Don't forget about the content editing experience for your Drupal sites. Leverage Drupal, don't work around it. If you build a nice set of roles and permissions, and look at how tools like Panopoly are making Drupal easier to use than ever, your clients will love you for it, guaranteed.
Isn't the fact that its so editable one of the biggest selling points of Drupal?
Exporting content is actually a really important thing to be able to do when you want to expose it to 3rd party services or even push/pull it between Drupal sites.
All the same issues that make it difficult to put content into Features - Like having a UUID for each node, dealing with fields that should or shouldn't be exported depending on the context of the export, like "last updated" or cron timestamps... These things can also make creating Feeds and Services difficult too.
While there's an argument you could make that some things should not be "allowed" to be "bounced down" into code as in the Features paradigm, if it helps, whenever someone says "Staging content before deploying it" think "Sharing arbitrary content between two affiliated/related sites through a generic import/export framework". The latter has a larger scope and there are lots of reasons why it is a good thing to have.
There's also of course the argument the UUID module makes that it can be very time/bug saving during development to use "structural" nodes. Not "html in a WYSIWYG" that you're worried about a client editing, what about the Webform module? what about Feed nodes?
What about just wanting things in code because you can *version control* them? git is obviously way better than Drupal's revisioning system.
I'd argue that if you're logging into client's production sites and making changes to their content for them through the UI, even if it's a node type that none of their user accounts have access to then you're "doing it wrong".