I have a POV that you should only use SharePoint for application development under these conditions.
1) The application uses documents and these documents need some sort of functionality that SharePoint does extremely well (searching/indexing, sync with Outlook, etc…) If all you want is a document bucket and a list then ASP.NET or ASP.NET MVC.
2) The application must use workflows or custom workflows. No workflow then again I would look towards ASP.NET or ASP.NET MVC.
3) The company must be willing to dedicate at least 1 full-time developer to SharePoint. Not 1/2 or a 1/3 of a developer. You need commitment and focus to do SharePoint development correctly. You must drink the Kool-Aid. If you are not willing to specialize in SharePoint, but only willing to dabble, the resulting solutions are terrible (IMHO). Even better if you can dedicate two developers or a team (think supportability / maintenance / expertise / specialization).
So what do you think?
note: I think all Microsoft shops should be using the out-of-the-box features of SharePoint if their company has chosen to pair that with Exchange as part of their collaboration architecture. I'm not anti-SharePoint.
UPDATE
After sitting in a SP workshop I have learned that SharePoint Workflow is only applicable on a per SharePoint List item basis. Therefore, if your workflow doesn't use SharePoint List items, then you should probably look at .NET Workflow foundation or something custom. Consider this a replacement to my #2 item.
Best Answer
I would agree. Sharepoint currently (moss 2007/wss 3.0) makes custom dev a very painful and slow process. The only point I would disagree with is the workflow portion. In my opinion the workflow in SharePoint is nearly unusable, and should be avoided. If you are going to do workflows, go for k2:blackpearl or MassTransit for the open source free option.