Absolutely.
Thankfully, the Docker team seems in agreement with this based statements about avoiding making Dockerfiles "too clever" and the response to various proposals.
As you point out, most of the "issues" here are really misconceptions.
I expect it's a tough balance for any new(er) project. Maximizing exposure and adoption, but avoiding negative perceptions from being applied in ways aren't optimal.
My experience (over the last year) is that they're so limited as to be pretty useless. They don't even do what they're advertised to do, ie give you a reliable way to reproduce a build, and they're inflexible for my idea of real-world work with Docker. Where they're good is in giving everyone a point of reference.
I had a discussion with the maintainers last year about this:
https://groups.google.com/forum/#!topic/docker-user/3pcVXU4h...
I have a problem with most CM tools in that they're for moving target systems, not immutable ones. Ansible is the closest, but our experience has been that development on it is slow relative to the tool we use (see below). It's saved us a ton of money.
I blog on this and similar topics here:
http://zwischenzugs.wordpress.com/
The "tool for building and maintaining complex Docker deployments" is here:
http://ianmiell.github.io/shutit/ https://github.com/ianmiell/shutit
I also talk about this here:
Not exactly, as the thread you link points out you can reference an image ID in FROM rather than the name:tag which has potential to change silently.
It's the equivalent of using a package manager against a repo you don't own without pinning - expect problems.
This can be mitigated by FROM'ing via ID or avoided entirely by running your registry where tags are reliable.
Admittedly, these things are not necessarily obvious, but I think it's a bit disingenuous to paint Dockerfiles as worthless or broken.
That said, ShutIt looks very cool and seems to address exactly some of my concerns / desires about working with Docker.
I just don't agree with framing it in opposition to and at the expense of what exists.
There's value in a container description that is fully self-contained, transferable and 'dumb' enough to be transparent.
Having done _lots_ of builds lately I can vouch for that (see my blog for some examples).
In the end the image ID _is_ useful, but the dockerfile itself has limitations.
I agree with your last point as well - my evangelism comes from solving problems at my company in this way (which I know are not uncommon problems) rather than any belief that it beats others objectively.