So without the aggregation/distinctness how big would the result set be?
I assume the change in speed is because of the disk io from creating the temporary table before condensation. They can sometimes grow pretty massive, I was working on some Oracle the other week and the query design at that point was sometimes creating 120GB temp tables so were completely unrunnable(unless you like waiting for 120GB to be written and condensed before output). The table was indexed properly but the way the query was written just made it hard for the optimiser to pick the smallest path to follow before shrinking the result set down causing large io issues.
The limit here is probably helping the database stop forming a very large dataset it has to work on before aggregation etc. It is interesting stuff though as working with both databases and application front ends far more benefit can be gained from understanding the database than doing weird ass optimization stuff in the application. 30 second white screen timeouts can sometimes easily become 1.5 seconds by giving it the right nudge. It is also something that needs to be given more active discussion, 6 seconds to 1000 people is over 1 1/2 hours of possible stolen life force. What is avoidable is stolen, whatever the users perception and level of patience.
The slow query log and explain are very good friends
Looking at your query( I can't see it or you data etc ) what path do you think it is taking with the limit clause which is slightly different from an unlimited query. What effect does the left join have on the data when joined? How does it act as a rowset multiplier in the temporary table etc? Is it 1 to 1 or 1 to 10000... Does playing with the memory configurations in the conf file help? 3000 is not a lot of rows so 6 seconds could be deemed high. Step the limits by 200 and see what point the temporay table is created and see what effect it has, if you are really anal chart a possible perfomance curve as the mathematics of the query unfold.
This page lists the conf params in bold.
Possibly there are a few more but I haven't really touched MySQL in years and it is the first thing I grabbed off google and skimmed so I have not double verified and memory may be shaky if they are still valid( article is quite old). As you seem genuinely interested in why this might be happening I thought I might give you some research material. Building things that scale more flatly allowing greater use of the current available database hardware is definateley a good but too ignored skillset in the developer community.
As I am a developer I leave a couple of final sentences just to annoy any database people to remove any perceived belief that I have any respect for the little furry databases.
"A database is just a glorified Excel Spreadsheet isn't it?"
"Indexes? My l33t coding skillz removes the need for any to be put on"