Why would I not run "index reorganization" regularly? I tried index reorganization queries several times so far. They look like this:

ALTER INDEX ALL ON TableName REORGANIZE


Such query may take hours but it looks like it doesn't interfere with other database operations. For some table its effect is next to nothing but for some tables it actually saves like 15% of overall database space.

What if I just run this query for all indices every week or so? Is there any reason not to do so?
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.