I don't have a solution or work around, but I remember seeing that too with different loops. My non-solution was to not include the print/AddMessage in the loop once I knew it was working. I decided having messages coming out after the loops was complete would be more confusing to others running the program than having none. Once you remove some of the "debugging" messages like SQL and row counts, it may not look as bad to the end user.
if I had to render a guess as to why it is happening, I would say the cursor is running thru faster and setting the SQL and row count variables faster than it can the updates and it's just spitting them out as they change. I don't know if in reality that makes sense or not, but that's how mine appeared, and many times mine didn't print until the cursor was completed.
You can maybe slow it down with a sleep function if it's critical. I know for some of my scripts, I have to build in up to 5-10 second delays because my script thinks a process is complete before the system catches up. This is mainly for fgdb deletes and renames, but the point being, sometimes script, processors, hard drives and the OS don't always seem to stay in sync. My opinion, fwiw.