I'm fine with engineers fleshing out the technical specs(who else is gonna do it anyway?), but requirements come by engaging with the stakeholders, as you said, most notably your client(s).
And this is not a job for your engineers.
It's silly and counterproductive for engineers to expect managers to be all-knowing seers, and then act disappointed and put upon when those managers inevitably make mistakes. They're human too. Find a way to work with them productively.
Obviously an engineer is involved in the shaping of the requirements by interacting with the product manager or whoever(never the client). By asking questions, making inquiries and sometimes even poke holes into user stories that ultimately don't make much sense.
No one is all-knowing, no requirements are perfect, etc etc.
What I'm saying is that it's the job of the (Product) manager to understand what the client wants and to relay this into more tangible terms to the engineers.
As for knowing the business domain. Meh, sometimes maybe, but I can think of myriad of situations that it doesn't matter and it may not even make sense.
If you have dozens of engineers and you expect all(or most) of them to be familiar with the business domain, I'd suspect there would be some serious management/organizational problems in that company.
Often however, the manager takes a bit too much "artistic liberty" in relying what I said to the client, usually announcing features as done when that's not remotely the case or worse still, selling features as done which I don't even know about yet.
I've also learnt that when a client asks "How long?", the manager seems eager to give an eagerly short date, usually around two weeks, for even complex feature, before consulting the engineers and has the whole "I know what I am talking about here.", attitude.
No matter where I've worked, most product is basically no one knows what they want until its built and sitting in front of them.
Right now we have a designer making mock up pages for me and we have a deadline. He is adding a fair bit of stuff that will need to be done with a mix of back end code and JavaScript. If we do things slightly differently I can code most of it in Django. If we do it exactly as he has done, i will need slightly less Django code, but the same amount of code again in JavaScript. Plus I find it better to have as much logic in the back end, rather than jumping between JavaScript and Python to work out where bugs are.
The designers must always collaborate with the engineers, if that's not happening it's bad project management :(
I also approve your tech/engineering choices :D
Probably slightly too B&W for the shades of grey of HN.
Practically speaking, engineers wearing both product & engineering hats are effective and sometimes crucial part of the process. Obviously more so in LEANer teams. And less so long-running enterprise projects.