That does look like rough going... though in my experience, a nasty-looking mess like that may not be so bad if you simply format it -- with indenting to indicate subquery levels, and maybe some color (like light grey for formatting/null check fluff and bold for SQL keywords).

Often a massive query like that indicates business logic and even display details built into the query -- are there lots of WHEN clauses? Big chunks of the query just managing formatting the output?

If SQL is your "hammer" to fix every problem, you can take a simple query -- say, fetching a user's full name and address from a single table -- and make it really damned long just by cramming everything into the query... is there an address2? A middle name? Did the user capitalize their names (you could fix that in SQL...)? Etc..

I have written some very long SQL before -- a few years ago I flattened many many pages of buggy PHP into a dozen carefully-designed (but a bit complex) materialized views that were the base for the final reporting queries (which could be pretty straightforward; the data involved was already neat & tidy).

If you blew up each view involved and removed all formatting, the reporting queries would be pretty tough to digest; that's the point, though -- all of the complexity was cut up & compartmentalized into well-named bite-sized pieces, so other developers were still able to maintain and extend it after I left.