It indeed is all about priorities. And the line you quoted from my previous post still stands, and your follow-up post, and post before that are both valid as well.
If using a WYSIWYG GUI application is the means to the end (making money by delivering a website to a client that matches the client's expectations) then, like before, there is no need for text coding.
(unless both ways take the same time, in which case text coding tends to be cheaper - but that doesn't make a difference in the Text vs WYSIWYG idea)
For some 'websites' that have a couple of 10,000 hits every second, and that 24x7x365, a few microseconds and a KB here and there translates into massive time and bandwidth savings :) Those are the cases where text coding is required.
For some clients of mine, that is exactly what they need, super speed, super small footprint, and it doesn't matter what I bill them for.
For some other clients, they don't even blink if the site would be a slapped-up FrontPage 1.0 homepage that renders every time you reload the page.. I adjust the quality and price for every job, since sometimes, work can be very dynamic.
I must admit that I haven't touched DW since the first Adobe CS version, but I never trust the GUI apps to deliver what I want them to deliver, no matter how I modify it's prefences or preview engines..
And since my text coding is probably just as fast, I usually don't mind doing the design by hand. It's a one time thing, everything, like content, is managed by the CMS.
Anyhow, it think that when someone reads this thread, that someone will probably understand that WYSIWYG gets the job done, if that's the job. (which might sound cryptic, but means the same as the blue line in your post)
90% of the jobs is such a job I think, but that irrelevant.