Well the discussions go further from the two big guns (Andrew Connell and Joel Olsen). The key takeaway was "not to reinvent the wheel". The SharePoint platform does a lot of things out of the box that traditionally you'd spend days writing, for example, CRUD data access layers and database schemas that can now be implemented using SharePoint Lists and the SharePoint API.  The other key areas are direct integration with back-end systems such as Active Directory ,BDC, Excel Services and Form Services.

Interestingly he does mention that if it is storing more than 5000 records a day that he would recommend it being stored in a separate database. Even with this, you can still use the SharePoint platform to be the presentation layer and take advantage of the deployment of the solution as a series of web parts etc. and all the underlying security model, navigation and everything else that is inherited from .Net 2.0 and ASP.NET Frameworks. Further on this, Digital Wave recommend that you don't let the native support dictate application requirements.

Joel does make a good point about just jumping on this and starting using it. There is a learning curve on developing in a team on SharePoint platform in terms of creating Solutions and Deployment packages. These things are becoming easier as tools are coming out for Visual Studio to bundle these things up in a more automated way such as the wsp builder.

Joel also mentions about keeping changes to Master Pages and Layout Pages in source control (externally to SharePoint) with the rest of the Feature code. Another practice I would extremely recommend to baseline a solution in one place. Andrew also highlights that there is no big deal in keeping all this in version control and having unit testing running on this.

I found some slams against it from an article on SharePoint Buzz in terms of it not being able to use XP/Vista as a development platform due to Windows Server 2003 requirements. Jeffrey Palermo I'm guessing made this statement and sees this as a friction against developing using SharePoint. I see his point terms of being careful with not just using SharePoint for every application you write especially if you really aren't going to leverage the main functionality of the platform because people will raise havoc in terms of setup times etc.

At the end of the day, SharePoint is just another platform on top of the .NET Framework with some very powerful tools that can save you lots of time in the right scenario!