Why is it a good idea in principle then? Automatic reformatting of the source code always seemed like a bad idea to me for precisely the sort of reason you describe.
It focuses developers' attention on the things that really matter - what the code does, and how it does it - by removing how it looks from the equation.
The point of an automatic formatter isn't to make the code look pretty. It's to make the code non-ugly, with as little effort as possible. Obviously, there will be cases where the formatter screws up and writes out something pretty ugly. The point is to train yourself to ignore these, because honestly time spent looking at, angsting over, and fixing bad formatting is about the worst possible use of your development time. Instead you could be thinking about solving a problem that hasn't been solved before, or making the product easier for a user to use, or refactoring semantic issues in the code that trip up developers.
It's good enough when you can configure it and apply it selectively. If I want to clean up a function in my code base, I can e.g. select it and run "perltidy" over it, which has a configuration dot file for the company code standard (or CPAN guidelines etc.).
Or just clean up some nags so that version control behaves better. But if the only option is not running it at all or having all the code automatically fit to whatever the people On High have deemed to be visually pleasing? Yeah...
It's irksome when the auto formatter does something ugly. Though, I think the issue is far worse with Perl tidy. With, gofmt my view is more "I don't like this bit but fuck it." Probably because, Go has much simpler syntax.
Both languages (being bastard children of C) often run into exactly the same problems, where the syntax doesn't differ greatly. If you e.g. are accustomed to having indentation without tabs, margins within function calls or prefer non-tabular variable declarations, you can have that in C, Perl, Pike, Java, etc..
