Yes, actually there are quite a few good reasons to not do that.

open( LOG, ">>", "log.txt" )
    or  die "Can't' write to log.txt: $!\n";
*STDOUT= *LOG;
print "Yay! This goes to log.txt! Success!\n";
# Reason 1:
system("echo Boo, this goes to the old STDOUT");
# Reason 2:
close STDOUT;
print LOG "Boo, this goes nowhere but I didn't close *LOG!\n";
# Reason 3:
open STDOUT, '>>', 'newlog.txt'
    or  die "Can't write to newlog.txt: $!\n";
system("echo Boo, this still goes to old STDOUT despite reopening");
[download]

*STDOUT = *LOG makes STDOUT and LOG share the same file handle in a way that is problematic to sane lifespan control. It also hides the old file handle for STDOUT away in a dark place where it will still get used by all manner of things that correctly know that FD 1 is how you send "standard output". And since FD 1 is kept open by this hidden-away, still-open file handle, open's careful work to try to make "open STDOUT" and "open STDERR" work correctly (ie. to have the first impact FD 1 and the second impact FD 2) is forever thwarted.

Just don't manipulate file handles by local()izing and/or overwriting perl globs. Lots of pain to be had there. And this goes doubly when dealing with the STD* file handles.