I have a 1.2Tb SQL Server 2008 R2 database which is more than 50% empty, because I migrated a lot of functionality to PostgreSql. The database is still in use, and still somewhat growing, but I do not think it will grow to use all 1.2Tb in the next 3-5 years.
At the current rate of growth, we are not going to use up 1.2Tb in more than 14 years. More to the point, we keep migrating functionality to PostgreSql whenever we need to make serious changes. In a very dynamic agile environment, this means we frequently migrate data away out of this SQL Server database. So, this database is likely to grow even slower in the future: it is being phased out, eventually.
As such, we'd rather use this unused empty space for other databases and such - moist likely it is not going to be needed for growing tables/indexes ever.
I recall that the rule of thumb used to be "never shrink databases". Does it apply in this case? Currently the server is running 2008 R2 EE, but we plan to upgrade to 2012 very soon. I think because this shrink functionality exists, there should be valid use cases where it makes sense to shrink. Otherwise why does it exist at all?
We can afford a few hours of downtime during a weekend.
Edit: the problem we are solving is as I said above: "we'd rather use this unused empty space for other databases". Also we'd rather prefer a solution that does not require investing too much time in learning the technology we are migrating out of.