After over 10 years of working in content management, I have come to realize that there is only one way to learn the value of managing structured information: the hard way — and that way is only 50% effective. People can intellectually accept concepts like content re-use and content/layout separation, but in the heat of the moment, few can resist the siren song of a word processor and the clipboard. Pasting in a bunch of text into a rich text area (and then re-formatting it) provides so much more instant gratification than data entry into the fields of a structured content form. It is only after a number of painful global content changes that people come to realize that the value of all that painstaking WYSIWYG work has a very short shelf life. It is not until a migration onto another platform that one becomes aware of all that semi-redundant content. But that realization only happens around half the time. The other half of the time the site's unmanageability is blamed on the CMS. A clear sign that the content manager didn't make the connection is when there is a requirement that the new CMS have a global search and replace feature.
As someone who has seen many companies succeed and fail (and really fail) with content management, it is easy for me to notice these patterns. But that doesn't mean that I can make anyone short-circuit his/her learning process. If I were able to forcefully impose a highly structured content model on a client, all they would notice was the complexity of the content entry forms. They would take for granted the downstream benefits. The best you can do is gently guide and hope that guidance will lead to recognition when the site becomes unmanageable. I don't get too worked up about it. If I get frustrated, I can just talk to my friends in the DITA/XML advocate community. Their pain in working with technical documentation teams is way worse.
In the software development world, we have the concept of DRY (Don't Repeat Yourself). The idea is "every piece of knowledge must have a single, unambiguous, authoritative representation within a system." I call the opposite of DRY WET (Write Everything Thrice) or DAMP (Developer Accepts Maintenance Problems. Hat tip to Brian Kelly). This means copying and pasting code (rather than referencing it) or writing the same data over and over again. Part of the development process is recognizing patterns and coming up with ways to reduce redundancy. Good developers are constantly thinking about maintaining the code they write because they will inevitably need to add a feature of fix a bug. And the feedback cycle is really short for developers. You write a bit of code, test it, fix it, write some more code, test that and the first code you wrote, fix it.... If you did anything stupid, the time you have to wait before suffering for it is usually short. I am not saying that all developers practice DRY, but they have a better track record than content contributors.
Most content contributors don't have that short feedback loop. Too often, content is considered a "set it and forget it" initiative. You publish and move on. But I am seeing two positive trends in the content management industry that may shorten the feedback loop. First, there has been some great thought leadership around solving the "post launch paradigm". Second, many CMS vendors are building in analytics and multivariate testing functionality that encourages the content manager to constantly tweak a website to maximum performance. My hope is that awareness of this functionality will compel buyers to think of their content in a more dynamic way — something that evolves and improves like software. Then maybe we will hear content managers talking about their websites being DRY, WET, or DAMP.