Bill, I haven't got a clue. But from my own attempts a few years ago I remember a similar situation that couldn't be explained. I then ran into Qlik support, and after a few WADs I simply gave up on using PRECEDING LOADS (except for the very simple ones) which essentially are nothing more than script-text-shortening techniques. Too much trouble, too unreliable.
In the end, in your case the exact same thing will be happening behind the scenes as in your original script: Resident tables are created to pass data from one PRECEDING LOAD to the next. A GROUP BY and an ORDER BY cannot be performed "on-the-fly"...
I did manage to behave (i.e. not comment) when reading this blog post: Preceding Load
I think it's a little bit different (or I would describe it a little bit different):
Your method to create an incremental number for a Site change is relying on Peek() function to address the un-goruped records, but I believe Peek() will address the records from the ouput table (which are the records that the top most preceding LOAD produces, the grouped records in your case). I think there is no method to address the intermediate records on their way from the bottom to top LOAD statement.
As Peter mentioned - and looking at the reports about preceding LOAD resulting in worse performance - I would also vote for your first script version.
Hope this makes sense,
sorry, I've just noticed that this thread is years old, it seemed to just popped up again...