Martin Fowler argues that even if we abandon Lines-Of-Code, still we CannotMeasureProductivity: "...Even if we did find an accurate way for function points to determine functionality...if I spend a year delivering a 100FP system and Joe spends the same year delivering a 50FP system can we assume that I'm more productive? I would say not. It may be that of my 100FP only a 30 is actually functionality that's useful to my customer, but Joe's is all useful. I would thus argue that while my direct productivity is higher, Joe's true productivity is higher."
I would say that Martin's made a slip, conflating coding productivity with software development productivity. I would say that, yes, the person who codes twice as many function points in a given time is a more productive coder. But the person (or team) that delivers twice as much customer value is a more productive software developer (or team).
Function points are to code what user stories are to software development: atoms of functionality. The fundamental idea of function points is that "Display a button on a form -- okay, that's one atom of functionality. Make a database query -- that's another." And that's how I also think of user stories: "Convert dollars to euros -- okay, that's one atom of client value. Allow the user to choose currencies -- that's another atom." Just as different atoms of client-value (user stories) have different, but short, development times, so too do atoms of functionality. But where the complexity multiplier for user stories is the Planning Game, the complexity multiplier for function points are the complexity matrices of the function-point counting process.
And, I would argue that it's not important that two large-system FP estimates might differ by factors of 3, just as you wouldn't be surprised by differences from XP teams forced to estimate the schedule for a whole deck of user-story cards.