As with everything - it all depends. SAP applications run with ddl_in_tran on all the time without any major issues. It even saved a few days of work when an errant transaction started to drop and recreate indexes and by killing it, when it rolled back, the existing indexes were still there.
However, like Rob says, there still are limitations - turning DDL in tran on will still not let you do so inside of a proc (he ref's a trigger - which is a proc)....
....there are times that you wish you could do this (e.g. replicating certain stored procedures) as there is few if any other ways around it. However, one aspect to be considered is that often ddl_in_tran is masking poor transaction management. For example, consider:
begin tran
select y.* into #mytable from x, y where x.id=y.id and x.col=value
update x
set some_col=#mytable.colname
from #mytable, x
where x.id=#mytable.id
commit tran
.....the ddl_in_tran in the above is simply poor transaction management. Even if you argue a 'holdlock' case, it is bad transaction management for a batch job
Soooooo....my answer is:
a) if trying to drop/recreate indexes and not lose anything if something goes wrong - then yes
b) if trying to replicate certain procedures....answer is we wish
c) depends on situation - possibly
Currently, in other cases, I would take a careful look at what they are attempting. It may be they are confusing a logical unit of work (and recovery of same) with a transaction....there is a difference - they may simply be wanting to use an explicit transaction as it is easier than designing the app the way it should be. Or, they may have a valid reason.....