SharePoint: platform, services API, or both?

Recent, SharePoint MVP Andrew Connell posed an argument to regard SharePoint from now on as a services API: Developers: SharePoint isn’t a Platform, SharePoint is a Service. His suggestion received multiple comments, mostly affirmative, some a bit cautious. A week later, Doug Ware published on his blog a reaction in which he warns against not utilizing SharePoint as a platform: Architects: SharePoint is a platform, treating it as only a service is a mistake.

My opinion in this verbal 'battle' with seemingly opposite perspectives is that both raise valid points. This is my addition to the discussion / position-taking (also posted as comment on Doug's post):

My view in these opposite perspectives is somewhere in the middle. In the past, the SharePoint community regarded and applied SharePoint as a 1) functional, 2) development and 3) deployment platform. The first still holds, for me it is ridiculous to eg not utilize the OOTB DMS features if you have SharePoint at hand in your company. The latter 2 however have changed: we can still use SharePoint to “build upon”, but we must not do that anymore by deploying to SharePoint infra. So for development, less to even no more regard / utilize SharePoint as platform in favor of services model; and as deployment model the SharePoint farm is in future-proof sense an absolute no-go. Note that also on functional level, Microsoft can unpleasant surprise with functions before strongely advocated, have disappeared in the next version. This is ao the result of the long design and development timespans for SharePoint as product itself. The bare essence of SharePoint 2010 was designed even before the year 2007, 2013 before 2010? In the IT world that is an eternity, the world is completely different. That is one of the charmes and benefits of online products, it enables SaaS providers (Salesforce.com, Microsoft, SAP, …) to respond in much shorter timeframe to new IT possibilities and changed market requests.