The reason they were using an old library version in the first place was likely stability: it was known to work with the rest of the code base.
So aside from 'merely' updating to the latest library version, they need to ensure that component still functions as expected. Perhaps this involves as little as just running a whole bunch of automated tests, or perhaps it involves more extensive testing involving real people using the stuff.
Then there is the fact that the Android team having an updated release is not that same as the carrier having the updated release, and here is where I suspect the slowdown might have been from.
As pointed out this is the first update to the phone, and most probably the first real test of a chain of command running from the security team, to the developers, to the release engineers, to the testers, then handed off to the carrier (possibly involving at least one face-to-face meeting), through their testing and release process, and finally pushed to the phones.
And for a first update, especially involving all the corporate hell that dealing with a long-established Telco is likely to entail, I think 2 weeks isn't all that bad.
Android's security design is such that the vulnerability was mitigated before anyone even knew about it, and so they are afforded a little extra slack in managing the risk of leaving the hole unpatched vs. mucking up a hastily pushed release.
There are possibly other factors involved too, like, what would happen if the first ever update did screw up the phone? This might cause unending pain in the future for the company if their Telco customers don't trust the updates coming downstream, and may delay future updates even longer to ensure their worthiness.
A final note is, for the above reasons, time-to-response isn't always the most useful metric to judge a product's security by. 2 weeks of a remote root hole is a little different to 2 weeks' ability to DoS a web browser sandbox, or perhaps, spy on a user's WAP sessions.