There's a reason why this is important - it allows the 'native' app to stay up to date with the desktop web app. Yes, the Facebook native app is less usable and more clunky than it was before - on the other hand, it's feature-by-feature more up to date with the main site.
Is that a trade-off worth making? Perhaps, perhaps not - but in the very least, there's an argument to be made, right?
There's an argument to be made, but I'd still argue against it :) As a user, I'd much rather have a polished, pleasant to use native app that lagged behind a feature or two occasionally than unified junk. As others have pointed out on this thread, FB's gotta have the dev resources to do separate versions (though maybe not the kind of developers happy to be working on such a "boring" problem).
I think code reuse is often a chimerical holy-grail because in and of itself it is not a good thing; what matters is user experience, the amount of development work, how easy it is to fix bugs, &c. But developers still often obsess over code reuse, even at the expense of things that matter.
Often, code reuse leads to less bugs and less duplicated effort which leads to more time spent on important things like features and usability.
Except that, I don't disagree with anything else you said.
Fogbugz has their own custom compiler that generates code for the platform of their choice. Facebook has already written their own PHP->C++ compiler. I wouldn't be surprised if they have some team there working on some high-level infrastructure that lets them write UIs and code that gets compiled down to custom Objective-C/html+javascript/AndroidJava/etc...
There's a reason why this is important - it allows the 'native' app to stay up to date with the desktop web app. Yes, the Facebook native app is less usable and more clunky than it was before - on the other hand, it's feature-by-feature more up to date with the main site.
Is that a trade-off worth making? Perhaps, perhaps not - but in the very least, there's an argument to be made, right?