The problem is low level bugs have a tendency to have their tendrils in far more places than it appears.
Fixing a bug in 14 days? That may be reasonable if it's an application like Microsoft Word, but even then it likely isn't enough to be realistic. Even Google's 30 days was unrealistic.
The problem comes down to how central the component is - there are things where you need to do full regression testing because it's such a critical component that any change could break something.
If you demand a fix in 14 days, the easiest and quickest fix is likely the one that harms security for all - disable BitLocker. The option already exists and can be deployed with minimal testing in days.
But if it's deep down within BitLocker, then 14 days likely isn't enough - if it's a simple fix, it might take a day to go through the basic builds and sanity tests, but then you need to run through a ton of other tests because it impacts user data and you need to make sure the change doesn't introduce an edge case where users might lose their data.
Even small chances become big with big numbers - a 0.01% chance is still 100 incidences per million users.
Even in Linux the issue happened - Dirty Frag is easily mitigated, unless you happen to be using those modules where it can be exploited. And even then the fix isn't validated, there have been more similar issues found. While Copy.Fail was reasonably self-contained - it was just reverting a patch, and Dirty Frag was a simple check, who knows what the real fix is? It might result in a fix that blows up in people's faces because the patch had to come out and there was not enough time to test it.
At the same time, it isn't unheard of for patches to not fix the issue so a patch came out, then two weeks later a new one comes out as it wasn't properly patched in the first place Rushing never solves any problems, only makes new ones.