I dont know about you guys.. But in that video he was still lagging like crazy once he got to the town.
There's a problem with the word "lag", which makes me avoid using it entirely - it's used to describe a wide variety of unrelated phenomena. Generik's frame rate dropped noticeably while he was at spawn, but that has entirely to do with client side performance, and nothing at all on the server. The problem they're trying to address is server performance. He was able to break blocks just fine at spawn without the server sending him back in time, which means the server was performing well.
The reason blocks sometimes reappear for a moment after being broken is something like this: The server attempts to tick 20 times per second. If simulating one tick takes longer than 1/20th of a second in real time, the server is unable to keep up with the speed the client assumes it's running at (and in fact, the Minecraft server spits a message out to the log when this happens; something like "Can't keep up! Did the system time change, or is the server overloaded?"). The client thinks the player spent x ticks mining the block, while the server has in fact only run for y ticks, where y < x. Client says "I broke this block", server comes back and says "no you didn't, you've only been mining for y ticks" and tells the client to put it back. Once the server catches up, it says "OK, you've been mining for x ticks, this block is now broken", and the client removes it again.
If your frame rate drops, it's due to the client running too many computations or rendering too much geometry at once. This is why I'm suspicious when people point to things like microblocks as a potential source of the problem they're seeing, or at least I was until CovertJaguar's post explaining that they're implemented as tile entities, which adds CPU load to the server per tick for each one. If not for that, they'd just be an extra load on the client side GPU for rendering, and have zero effect on server performance.