I abhor having to learn a complex system/framework when such things as technology is a moving target and there is always another system/framework waiting to break-ground, were all the kool new-kids want to be. I just want to get my work done, go home and enjoy my life.

I personally wouldn't know where I stand, because I am not sure what simple and complex tools are, esp. if this is supposed to be a clear dichotomy. Does "complex" refers to internal complexity or complicated UX? Are some tools simple when doing simple stuff and annoyingly complex otherwise? Is the complex orchestration of 100 simple tools different from using 10 more complex ones? What are the complex tools "A" guys are shooting at (IDEs, scriptable text editors like Vim/Emacs/etc - damn, there was a point I was reading emails with Emacs -, Git, Rails)?

So, for me it's sort of an in-between thing. I do have a number of tools in my tool chest of which I would claim that they do at least an ok job at being easy to start using and helpful when the going gets tough. However, for the work I am currently doing the ramp up time was pretty awful again …

Oh, and I'm not a mathematician but a practitioner of almost 30 years experience. My professional roots are in banking and (micro-)economics.

Count me in for the A group, please. :-)

Also, Emacs is complex, but not complicated due to okayish modularity.

If this is true, it will cause an apparent skew: older (extant) tools are simpler than newer tools (which have not been through the same crucible of cross-generational adoption).

The question is not complexity vs simplicity. It's a question of comprehension across time. As we get older, most of us come to appreciate code that is written such that we can understand what it does with minimal effort. The overall cyclomatic complexity may actually be quite high, but the code can be very "simple" in that it's obvious what each modular part does and why. When we're younger, we tend to focus on just getting to the objective, by whatever means necessary. This approach is effective until we come back to that code a few short years later. This is true not only of our own code, but of components and libraries that we use.

So, if we rephrase the survey to "do most programmers value "simplicity" (i.e. clean, readable code) as they gain experience?" the result is likely unsurprising.

Single use tools are nice when your domain is mostly static. You have a problem and a single-purpose tool that solves it. Life is good.
Then you have another problem which is 2% different.
Do you build another tool from scratch?
Do you duct-tape extra functionality to the first tool?
Where do you stop?

As an engineer, I think I like flexible stuff with simple wrappers and sensible defaults so they all look simple from the outside, so A.

In my experience people who believe B rarely know very many tools to the depth they consider adequate. There's a basic law of conservation of attention at work here.

More to your point, ever since I started programming for real I would first try to use the simplest tool available and only when that fails go and dive into the more complex tool.