A one-line query is easy to read. A five-join query with nested subqueries and a dozen conditions in the WHERE clause is not, until someone puts every clause on its own line and indents consistently. That's all a SQL formatter does. It changes the layout and leaves the query's behavior alone.
select u.id, u.name, o.total from users u join orders o on u.id = o.user_id where o.total > 100 order by o.total desc ↓ SELECT u.id, u.name, o.total FROM users u JOIN orders o ON u.id = o.user_id WHERE o.total > 100 ORDER BY o.total DESC
Keyword collisions with identifiers
A naive formatter that matches keywords as substrings can misfire on a table or column name that happens to contain one. A column named from_date shouldn't get split at FROM, and a table named deleted_users shouldn't trigger on DELETE. A correct formatter tokenizes on word boundaries, so it matches FROM only as a standalone token. It also tries the longest keyword first, which keeps DELETE FROM together as one clause instead of breaking the line at FROM.
Dialect differences the formatter doesn't know about
Generic formatting (indentation, keyword casing, clause line breaks) is dialect-agnostic and safe across MySQL, Postgres, SQLite, or whatever you're using. A generic formatter can't validate dialect-specific syntax, like Postgres's ILIKE, MySQL's backtick-quoted identifiers, or SQL Server's TOP in place of LIMIT. Formatting won't catch a query that's invalid for your database. It makes correct queries easier to read, and mistakes a little easier to spot by eye.
Comments can get separated from what they're describing
An inline comment (-- explains this join) placed at the end of a line will sometimes end up on its own line after reformatting if that line gets split. If a query had inline comments, look at them after formatting. Behavior doesn't change, but a comment can end up looking like it describes the wrong clause.