Dropping unused indexes - Assessing the unexpected dangers
Your DBA's concerns are both valid.


  Regarding #1, it seems to me that SQL Server would actually do a seek on the index to determine uniqueness before an insert / update is done, and therefore, the index wouldn't show as being not used.


The uniqueness guarantee may be used by the optimizer in deciding which logical transformations or physical operations can be used to obtain correct results. The fact that the optimizer relies on a uniqueness guarantee to, for example, transform an aggregation or choose a one-to-many merge join, will not be reflected in index usage statistics, unless the index is also physically accessed in the final execution plan. One should therefore be very careful about removing (or disabling) any unique index or constraint.


  Regarding #2, is this really possible?


Yes, it is possible for the optimizer to use statistics associated with an index without the final execution plan featuring any access using that index. The processes of loading 'interesting' statistics, calculating cardinality estimates, and producing a finished execution plan are quite independent activities.

Dropping the index would also remove the associated index statistics, which may affect plan quality next time the statement is recompiled. The index statistics may be used in a cardinality estimation calculation that the final plan relies on, even where the index is not physically present in the final plan.

Your DBA knows his/her stuff.

None of this should be taken to mean that apparently-unused indexes should never be removed. I'm simply saying that your DBA's concerns are valid ones, and you should plan the change with them accordingly, with appropriate testing, and a recovery plan. In my experience, point #1 is more likely to be problematic than #2, but I have no way of knowing whether that applies to your situation.