While I understand your point, I feel like mine was missed. Perhaps I should have worded it differently. The fact is, the web is a constantly evolving ecosystem that as a front-end engineer, you do not get much control over. Yes of course the code YOU produce should be predictable and stable and so forth. However, at any time, the rug can be pulled out from underneath you by a browser update, the uptake of a particular device (e.g. iPhone), etc. When you are working on a website where the WebKit nightlies compose more of your traffic per day than most of the sites on the rest of the Internet get in their lifetime, you have to be extremely flexible in your interpretation of what a successful feature looks like when applied across the board. I do not feel that one faces this same level of constant uncertainty in backend environments where the engineers have much more say in what is running their software.
The wonderful and terrible thing about front end development is that it's hacks built on hacks. Really pushing what browsers can do requires the acceptance of this and the willingness to put in even more hacks so you can package a relatively leak-free abstraction. It's that creation of abstraction that marks front end engineering and what we should be striving for. I work at a web shop of 30 where we have a dozen people who fit the criteria in your article more or less exactly...and they're our designers. What separates our front end developers is bringing algorithmic efficiency, knowledge of browser internals, separation of concerns, development methodologies, testability, etc. to the code our designers write. It's accepting and working with the instability while knowing and building towards the stable that makes front end engineering what it is. That and the intricicacies of how browsers interact with the standards and a working knowledge of the design disciplines.
I think the point where we can meet is that it's easier to teach a good web designer+beginning programmer enough software engineering to be useful than it is to teach an expert developer browser quirks and design.
I think a big part of the reason hiring for the front end is difficult on top of the wide skillset is the discipline didn't even have a name three years ago. I spent years ('03-'06) trying to figure out a job categorization for myself that wouldn't have me doing graphic design or writing stored procedures (I can do both competently but not well). For a couple years, just the fact that I knew "Ajax" opened doors and it took quite a bit of work to wrangle through the various browser quirks but as tools advance the discipline--and people expand their skillset--a much wider set of people have the page scripting skills that were cutting edge in 2005. Similarly, the rise of the second level of javascript libraries (KVO, MVC, MVVM, Modules, etc) will allow more people to build more stable solutions and the general practice will be what's cutting edge today. I expect this second stage will make it easier for the back end developers to transition over, though I suspect the dedicated static language people will continue to have trouble.
