There's two kinds of updates:

1) Security and coding bugfixes - these correct problems with an existing release, which might contribute to lag, but also might expose your account or activity to others. These cannot be deferred easily - sit on the update, the problems that update fixes keep happening, and people get upset.

2) Added Features - these add or change the capabilities of the viewer itself. Maybe they are faster, use less memory, or make the SL world look better. There may be Quality of Life changes, wherein features that make SL easier to use, easier to learn are put in. These can be deferred, but keeping such updates in 'limbo' means they aren't effective at retaining or attracting residents, they're just code sitting in a library doing nothing. So at some point a Feature release needs to be made.

Then there's the Third Party Viewers (TPV's) such as Firestorm.

These teams use the Linden Viewer code as a baseline, and add their own ideas on top of it, or slightly change how it looks and behaves while keeping the under-the-hood functions consistent. They have the same update concerns above, only now there's two more:

3) Maintaining Viewer Parity - this is when a feature in one viewer isn't yet implemented in the others. Users of the ones without may start clamoring to get these new bits implemented, which puts pressure on the dev teams to vet the code, test it, and then release it.

4) Backwards Compatibility - in a perfect world, LL would coordinate with the TPV teams to do updates on the same dates, so that changes to the official viewer would be reflected in the TPV's with no delays. But, real world coding logistics apply. There's no way that one team would blindly accept changes from another team they don't work with every day, without testing those changes to see if anything in THEIR build gets broken. Likewise, the official viewer development wants to be sure that the TPV's truly understand the coding changes, that there's documentation and other help available, and so on. This all adds time to how patches progress from one group to the others. So there has to be some leeway for an older build to still run on newer server code, at least for a while, to give these largely volunteer dev teams the space and time to do their thing. That means that old cruft-ridden code sometimes has to stay in place, if only to make sure that Viewer X doesn't crash out until their developer can get some coding time in.

Hello, and thank you for your feedback regarding the updates and performance issues in Second Life. We understand your concerns about the updates causing lag and slowing things down. This issue has been brought up before by another resident and is tracked under issue number BUG-8889 from Second Life's previous bug tracking system. We are merging your comments to help address this faster. While we don't have an estimate on when this might be resolved, please keep an eye on future updates. We appreciate your input and hope you continue to share your ideas to help improve Second Life. Thank you!