Most uses of a language don't require mastery. Especially if the rest of the team knows better than to write unnecessarily clever code when boring code would do just fine.
I don't think it has to do much with clever vs. boring code, but it's more about knowing your idioms and avoiding pitfalls. When it comes to mastery I think most recruiters prefer the master over the novice.
I think it takes at least a year to learn OO design enough that you can write code worth (re)using. The Java ecosystem is also so big that it takes years of experience to really get your head around it. And don't get me started about C++.
Sure, a decent coder can learn to write "hello world" in any of those languages, but if you need to pick up a legacy system and understand what's wrong with it (I think this is 80% of the jobs) it takes depth. If you've got enough depth in how systems work you can get sort-of up to speed in various languages quickly, but there's no substitute for taking the time to know the details of what you're doing.
As for LOB work I can say that LOB systems can be a lot of fun to develop. Your average e-commerce or social media site is basically an LOB system. Developing a system of practices that lets you deliver LOB systems on time and under budget is a challenge, but in the right environment it can be done and there is something very satisfying about delivering something that makes people's work easier.
The trouble with LOB work is that it's usually not greenfield work when it comes to you. They had some junior guy who never heard of primary key integrity build an app in an access database and a year later the database is full of junk and the app doesn't really work.
The process of rebuilding the schema is tortuous and then you need to update every single screen and script to work with the new schema and then there's the long and involved process of reconstructing what the database contents should have been with minimum data loss.
Although maintenance programming can really widen your skills and ability to deal with "it" there's also something destructive about spending all day deeply understanding the logic of terribly flawed code.
Managers would prefer a master, not recruiters. Recruiting requires throwing everything at the wall that remotely looks like a fit (I know .NET, am not a master, but it's on my LinkedIn - every freaking unsolicited recruiter contact I get is for .NET) Also, if they can get a novice in there, there's a chance they can pay less yet bill the client the same (talking on w2 contracting here)
