After my last post on this topic Alan Smith left a comment on my blog.

His comment was a good point and is worthy republishing here, to round out the topic.

Here it is verbatim:

"I'd agree with you there that quite a few .net ppl will try to solve problems with C#, rather than learning the correct way to solve things in BizTalk. I spent my first few weeks thinking "I can do this in 2 hours in C#, why does it take me 2 days in BIzTalk?". As you get your head aroud how BizTalk works, you do things in BizTalk in 2 hours that would take 2 days (or 2 weeks) to do in C#.
But there's also a catch 22 here, if I was hiring a BIzTak guy, i'd pick someone who was a good .net (or java) developer. Even though you don't 'usually' write much code, there are situations when you need to, and you need to have good programming skills to do so. Custom pipeline components, custom functoids, and C# utilities to call from orchestrations are usually required (ok, maybe not functoids) on most BizTalk projects, and the code for these component needs to be solid.
Along with the dangers of having .net ppl solving everyting with C#, you also have the danger of ppl who are scared of programming jumping into BizTalk development because thay think it's easy, and think they can build apps by drawing things."

It never occurred to me that a non developer would look at BizTalk as a way to dev work with out code. Thats never gonna work. BizTalk is well and truly a developer technology.