What you are saying is right. The database should not be shrinked. However there are some exceptions.
Let's say you move a lot of historical data out of your DB and it goes down from 100GB to 10GB. You may want to reduce it back to 10 or 20 or 50GB.
The thing to remember when you decide to go on with a shrink is that data (clustered and non clustered indexes) will get (possibly highly) fragmented. By data in indexes, I mean that rows won't be ordered by the indexed columns and stored continuously on continuous pages anymore. The server will have to jump through pages to read continuous rows (=> more IO).
Therefore, after a shrink you should defragment or rebuild your indexes. Choose for each index if it should be rebuilt or defragmented based on their fragmentation percentages.
You probably already have a maintenance plan taking care of this so you just have to run it again right after the shrink.
If your need their support, you might have to make them happy... The guy asking you to do it probably know nothing about SQL Server and is just following a written procedure.
In that case, you may proceed with the shrink and then update the indexes.
Note that I don't know much about Enterprise Vault.