The biggest advancement that libav brought was forcing the ffmpeg maintainer to get off his ass and actual lead the project. Shit would still be stagnant if libav didn't come around.

When people say "gratuitous and destructive forks", they aren't referring to the fact that a fork was made, but the method that was used. Instead of cleanly making a new fork, they tried to take control of ffmpeg itself, making the situation worse for all. They also perpetuated a rumour that the ffmpeg project was dead, when it clearly wasn't. Often just the fact that you make the fork is enough to revitalise the development of the original project, or it will stagnate naturally as people use the fork.

As a recent example, no one has tried to take over openssl's development. A number of "fixit" forks have been made, and either openssl will lift their game, the forks will diverge, or they'll be merged back together.

Forking is not that much a problem when it's limited to a program. Typically in the case of MPlayer, you had mplayer2, and nowadays mpv, and this is fine really. It's just a program that could live with the others without much trouble.

On the other hand, with a project like FFmpeg which actually provides libraries, it can really hurts the users community. Especially when the forking is made without changing the library names... which is exactly what happened here (thanks to the confusing name of the fork, chosen on purpose).

Basically, the fork was made such that only one can survive (example: only one "libavcodec" can exists), because they were actually confident about the outcome. But it seems they didn't anticipate such fundamental changes in the way FFmpeg continued to live.