When you work with WPF for a while, you realize that a lot of people who decide to share their knowledge are probably dogmatists. The dogma seem to be that separation of presentation and data is paramount, any mixture of code and presentation is evil and must be avoided at all cost.
I might be wrong about this, but I think we are hinging a lot of the examples on the facade pattern. The idea that you create different facades depending on the presentation context. E.g. a geometric object – say a circle – does not know anything about the presentation. To present a circle to a user, a facade is created. If the context is a web-page, the facade might create a PNG and return it to the user, in a regular app, we might just use GDI to draw a circle on the screen.
This frees the Circle-developer from knowing anything about HTML and mime-types, or GDI, or if a new technology comes along we just create a new facade. But the flipside is that the interface between the circle and the facades need to be fairly static. The circle dev might decide to add color to the circle, but now the facade developers in the other end of the world need to update all their circle presenting facades… ugh..
I like to have object “render themselves”. I think this is a little more object oriented. If I decide to add color to my circle object, then I will need to fix “drawToBitmap” and “drawToScreen” in my class (or inherited classes). But it seems logical to me that when I change the object, I will frequently know if the change also affects the presentation, and subsequently require editing of the presentation FUNCTIONS (rather than classes).
If XAML is a hammer, some XAML tutors are seeing nails all over the place.