Why would I not run "index reorganization" regularly?
Reorganizing an Index should be done when you have elevated amounts of white space within your index (i.e. avg_page_space_used_in_percent column in the sys.dm_db_index_physical_stats DMV).  Many people (and even solutions) in the SQL Server community say you need to look at Index Fragmentation levels (e.g. the avg_fragmentation_in_percent in that same DMV), but this is not as much a concern depending on the type of underlying storage (e.g. anything that's RAIDed fragments your data for redundancy purposes regardless).  Others also have come to the same conclusion.

The downsides to Reorganizing your Indexes when not needed is that this operation will purge portions of your cache so it can have sufficient room to perform the reorg within memory. Reorgs aren't as destructive to your cache as Rebuild operations, but they will reduce your Page Life Expectancy (PLE) and potentially purge useful data that you will have to re-read from disk (e.g. increased I/O operations).  Additionally, Reorg operations do NOT update Index Statistics.  Updated Statistics do more to produce optimal executions plans than defragmented indexes, so if you're going to mindlessly run a nightly operation I would say Updating Stats is the better choice over Reorging instances.

The right answer though is to have a solution check your White Space thresholds and reorg/rebuild indexes when needed.  Have another process check your statistics and update when needed.  There are a few solutions out there, such as Ola's maintenance solution, Minionware's Reindex solution, etc.  But I often find myself customizing solutions to fit my needs.