The first key rule in this theming process is that there should be a strict separation of content and presentation. This means that the logic for putting together page data and the code wrapping this data in the presentational XHTML should be kept as isolated from each other as possible.
There are some very good reasons for this.
Keeping the poets out of the accounting
The first is that keeping data logic and presentational code strictly separated lets developers work within their respective skillsets. Back-end developers only need to concern themselves with database management, data logic, and query optimization, while front-end developers do not need to navigate this code to apply the XHTML structure. The themer uses their own dedicated functions as a sandbox for applying the front-end code to the back-end data.
Server-side gurus don’t have to write XHTML, and front-end experts don’t have to mess around with data logic. This helps to preserve the quality of code and reduce mistakes and reworking.
Adapting to new needs
The second main reason for this separation is flexibility. Keeping presentational code out of returned data makes this data reusable in different contexts—for example, in an unordered list on one page and in a table on another. Instead of writing an entire new query to pull the same data, one needs only to write new theming code for the new presentation of that data that has already been collected.
Staying focused and avoiding accidents
The third reason is for maintainability. Keeping content and presentation separate makes is easier to focus on required changes with less risk of breaking other aspects of the site. When the presentation of a piece of information changes, only the theming code is touched. The data logic stays safe, away from the code in flux. Likewise, the data logic can be modified and queries optimized without risk of damage to the XHTML.
How to do it
In Drupal, this is fairly intuitive. Dedicated theming functions are inherent to the system and facilitate this separation. When using Drupal, it's really a matter of following the stnadard guidelines--put no formatting (eg, XHTML) in your returned data, and put no data logic in your theming functions.
On other platforms, it may be necessary for developers and themers to decide on a protocol for creating a similar environment to achieve separation. At the least, custom development can be structured with functions dedicated to collecting and processing data, and separate functions that take this data and wrap it in the appropriate formatting.
While it may not be possible--or advisable--to modify all the modules and plugins a site needs, benefits can still be realized by separating content and presentation in one’s own templates and custom components.
Key takeaway: Strict separation of content code from presentational code discourages developers from working outside their true skillsets and makes the site more flexible and easier to maintain.