PS: John Eisbrener's answer is excellent advice to which, I would only add that, one reason you might not run this regularly, is that reorg/rebuild generates transaction log. Of course, the same is true of any major data operation.
If you are running a log-shipped environment, it might take significantly longer to ship that period's log-backup, which might have a (not always proportional) impact on your recovery-point objective.
I have certainly seen instances where a 5 minute index reorg has generated x gigabytes of log in the next backup, which has taken y minutes to transfer and restore, where y > RPO. Thankfully, so far, I've not had an actual DR issue during those y minutes, so we've always been OK, but it's not fun receiving all those LSAlert emails (default every 2 mins) because either the primary hasn't backed up and/or the secondary hasn't restored in a while.
Also, if you are running on a tight-for-storage environment or high cost-per-IO environment, the additional data might tip cost-tier thresholds, max your available storage or throw out your nightly offsite backup window.
Some people might argue that you shouldn't have to worry about such things, and that you should only care about how well the database is performing, but I see cost and recoverability as just additional dimensions in the n-dimensional set of 'good states' your DB needs to be in to be useful.
As always, it depends entirely on the logical or physical constraints in your environment and/or the needs and politics of your organisation.