The problem with all the date pickers that take text input is that they can't differentiate between 03-05-2010 being in March or May. I worked on some software for a company doing federal compliance consulting for employee hiring processes and requirements. We found that most people don't read (MM-DD-YYYY) type notifiers most of the time and immigrants were most likely to write dates as DD-MM-YYYY where as those born/raised in the US would write MM-DD-YYYY. When dealing with hiring issues getting those things wrong can lead to fines for the employer, incorrect eligibility for benefits for employees and other issues. What we ended up doing was having the date picker automatically show up and start moving to the date as it was typed in. If you entered 03-05-2010 and you meant May 5th 2010 you would see the calendar on March and then most users would switch to the date picker widget to correct the error.

Localized date pickers such as datejs don't solve this particular problem because all that happens is the assumption about what format the date will be entered in changes. So an American in Germany might enter MM-DD-YYYY and the date picker will just assume that it's DD-MM-YYYY because that's the format specified in the de-DE.js file.

I agree that flexible text entry fields are preferable, but I've seen several business cases for preventing the user from being able to enter the date any way they want due to the ambiguity in date formats.