I think people are missing the general point here:
If you don't like all the custom development that's going on,
forbidding it is solving the wrong problem - you should instead be
asking why they're going around IT, not just telling them it's not
allowed. Remember that you (IT) exist to help them do their job
better, and that people don't use software because it's cool or neat
or new, they use it because it solves a problem they have.
Why are these apps being created in the first place?
In all the cases I've seen, there's a common reason:
Business groups prioritize their own needs higher than those same needs are prioritized in the context of the whole company
Marketing is only responsible for marketing, so initiatives that benefit their goals seem critical to them, while being considered fluff to other groups, and tend to be prioritized lower when it comes to limited resources like IT. Prioritization only comes into play when they want to use a shared resource - if they keep the project entirely inside their own department, then only the department head has to care about the budget and timeline.
There's no reason I'd forbid this sort of development, within reason - it eases up constraints on shared resources (mainly IT), and allows each group to empower themselves to solve their own problems (as people versed in advanced Excel are pretty common, since this is a common problem, most departments have at least one).
However, you can't be expected to solve any problems that arise from these applications, or support them after the original developer leaves the company. As another posted mentions, this doesn't stop the big boss from demanding that you support it, but if you keep a feel out for the kinds of custom applications or processes out there, you can get a feel for when something becomes critical and you might need to get involved to bring it "in-house." Also, if something is connecting to and modifying systems that are under IT control, then IT should be involved, if only to ensure the security and integrity of their central systems - however, if it's something confined to a user's desktop, why feel the need to forbid it?
But here's something to remember: Every custom application that's been developed outside of IT corresponds to a need that's not being met by IT. There may be a good reason they're not met - not a priority in the company, very specialized problem, not as good as other options, custom language your IT people don't know, etc - and the lack of IT involvement may be legitimate, but these solutions were created because some department had a need that IT couldn't (or wouldn't) satisfy.
Try to help them solve their problems, and if you don't have the time or resources, let them solve them on their own. Mandating some language that has a steep learning curve, with the sole purpose of keeping people out of your business, only serves to enhance the elitist attitude most business users perceive IT to have, and in the end, that kind of elite attitude only leads to more of the same problem, as users are afraid to approach IT and are convinced that IT doesn't understand their needs or wants. Open the relationship - understanding what they need is the only way to keep them from going around you.