At one of my clients, there’s a debate going on about whether to control which development tools people use or not. In my mind, that’s a no-brainer; absolutely!
I say "Never let the inmates run the asylum." What I mean by this is that if you ask N developers what tools you should use, you’ll probably get N^2 answers. Developers usually shouldn’t make these decisions on their own. (I say this as a developer. I’d love to use Pascal or FORTRAN or assembler or FOCUS again, but would it make any sense???)
When I was 23 or 26 I always wanted to play with the cool new stuff, just like the 23 or 26 year olds today. What I didn’t have then was perspective on what works well over a long period of time. Now that I do, I know that the Wild West approach may seem like a good idea to some, but it’ll cause tears sooner rather than later.
Almost every organization I’ve worked with has an architect role or office that screens new tools and makes suggestions or edicts. How tightly the organization is tied to those suggestions or edicts depends on what type of organization it is. If a bank said "Let’s use whatever we want in our ATMs.", that would be a real problem. On the other hand, in an R&D environment, considerable leeway may actually make sense.
The academic model says "Let’s try anything and see what works."; the corporate model is usually more like "Let’s look at our overall strategy [the business strategy, not the IT strategy, at least first] and determine which tools will be the most productive and cost effective."
Cost effectiveness takes many forms: can we produce high-value solutions quickly and reliably, can we scale up our staff rapidly if we need to, can we keep up with new software versions reliably, can we build good institutional memory for maintainability, can we support our solutions, can we train our users fast, etc.
Now I’ve seen most large organizations totally blow it on this. The controls end up being the goal rather than the effectiveness and cost management. This usually leads to skunk works, or some other form of "cheating" to get things done. Letting the pendulum swing to far that way can actually cost *more* than the Wild West approach.
All organizations should have some sort of guidelines at least, and in most cases, stringent rules. As with SharePoint governance, there’s always a lot of "it depends", but there will be a right set of answers for every organization, and some sort of control is what is going to make the organization succeed in the long run.