Sometimes people have wondered why DateTimeFormatInfo.MonthNames returns an array of 13 months, or why there's a LOCALE_SMONTHNAME13. The answer is that some calendars have 13 months. The MSDN Calendar.GetMonthsInYear() has an example of when "leap" months are used in some calendars.
Microsoft.Net could have decided to return only 12 months for the Gregorian calendar, however it returns an empty 13th month, even when such months aren't used by a particular calendar.
Its worth remembering that non-Gregorian Calendars may do things that someone used to only the Gregorian calendar may not expect. Obviously calendars may have different numbers of months, but they also may have other interesting aspects:
When testing software with such calendars its good not to make too many assumptions. Similar to the Gregorian leap year, some events may be difficult to encounter or test. Narrow assumptions (February only has 28 days) may miss the rarer event (a leap year with 29 days.) In general its good to make as few assumptions as possible about the users date or time expectations and let the OS or the Framework handle details.
Calendars have also been added (UmAlQara in Windows Vista and .Net Framework 2.0), so its possible that future users of your current software may encounter different calendars that you can test today. Trying to avoid cultural assumptions and avoiding making expectations will make your applications more robust in the future.