40gb of tempdb isn't a lot (even if it's on SSD). For even a relatively small DW (say, a couple of TB in size), I generally aim for around 10% as tempdb (more if the DW and ETL are sharing the same system -- a couple of large online index rebuilds will blow out tempdb in no time flat).

While I appreciate the sentiments of the DBA saying "oh, the developers don't need that much tempdb", it's actually about getting the data out to the customers in the most expeditious fashion. Sometimes that means just getting on with it and not having to constantly worry about the "best approach"; there's an old saying that "best is the enemy of good enough."

The tempdb is one of those things where you can throw extra space at it to enable getting stuff done easily. Think of it as helping to enable your developers, if you like (and in most cases, developer time is the most precious resource of all).

You still need to keep an eye on what's going on and ensure that there is a process to get the inefficient stuff refactored (otherwise you will need infinite resources and processing power). From what you have described, you already have candidates in mind for that.

My suggestion would be to negotiate with the developers: you give them additional tempdb if they put in place a refactoring process. That way they can still do quick turn-around on data and query delivery, while you can ensure that long term your system doesn't bog down.