Thank you for the quick and diverse feedback provided so far. Some thoughts:

Sure, the perfect solution would be a MediaWiki extension deployed in Wikimedia and available for 3rd parties, but let me share why I think this is not possible within the scope of this exercise:
* The Technical Collaboration team has some budget available for FY2015-16, to be used by the end of June. What can be achieved within this timeline? Certainly not anything in the form of a new extension in the Wikimedia cluster. In comparison, the Phabricator Calendar improvements could be developed and deployed in Wikimedia within that timeframe.
* Who is going to develop that extension? After agreeing on a plan for a MediaWiki extension, we need to define who will work on it as paid work, which also takes time. In comparison, funding Phacility Inc for Phabricator upstream improvements is a straightforward and quick decision.
* Who is going to maintain that extension? The Technical Collaboration team doesn't have the skills to maintain it, and the Community Engagement department has a known problem of mid term sustainability plans of the software we commission and own. While other CE teams are trying to reduce and resolve this problem, TC cannot just start the development of a new extension without a maintenance plan.

When it comes to the technical plan, things are anything but clear:
The first requirement is **Introducing calendar data**, something that plain MediaWiki was not designed for. 
* SemanticMediaWiki is designed for semantic input, but I think it is safe to assume that Wikimedia is not going to increase its dependency on SMW when the trend on wikitech.wikimedia.org / Labs is the opposite.
* Recent efforts on developing extensions focusing on input of structured data via forms (limiting wiki editing in its purest sense) are being met by a small but perseverant current of criticism. Would this project conflict with that view (I don't agree with such view, and I wouldn't want to be a participant in such discussion).
* In previous discussions about something new, Wikidata was mentioned as part of the solution, and then the Wikidata team disagreed for reasons that I found convincing. Is this another of these cases? In any case, that would not solve the input problem immediately either.
* In comparison, Phabricator Calendar provides a way to input data designed for events, it is based on free software, and it is already deployed in Wikimedia servers.

I think that starting this effort by requiring native calendar input data in MediaWiki is not the best tactic. Once the calendar data is introduced and available somewhere via .ics, a MediaWiki extension could focus on its presentation in MediaWiki pages. That would probably solve better the 3rd use case, since I can imagine many orgs using MediaWiki that already have their calendars in Google, Facebook, or elsewhere able to export data via .ics.

I also want to note that output in MediaWiki pages is not the only destination of calendar data, and I would even contest that idea that it is the most important. I believe that most of our users would use this data integrated in their own calendars, importing Wikimedia calendars and following their updates from their calendar apps. That is also a reason why I am not obsessed with having MediaWiki output first, or as a requirement for any first step.

For all these reasons, I still think that improving Phabricator Calendar is the best first step solving our problems with calendars. A step that would solve most of the Wikimedia tech problems, and a step that would be in a direction compatible with solving the problem for the rest of Wikimedia, and other MediaWiki users.

The MediaWiki extension able to read .ics data and embed it in MediaWiki pages could be a good candidate for an Individual Engagement Grant. That program is well suited to evaluate movement priorities, feasibility of plans, and funding specific contributors, all done under a community review process. 

If we solve the Phabricator Calendar piece in the next 2-3 months, and the MediaWiki extension piece in the next IEG round, we could have a good enough solution for everybody by the end of the year or so.