<p>Our organization started on the SharePoint path about two years ago.  Before that, we (the developers) wrote mostly asp.net front ends for SQL back ends.  Now it seems like every time a new project comes up, we are asked to “make” it fit in SharePoint; and we have stuffed some things into SharePoint that probably should have been stand alone applications or web applications due to complexity and interactions with other technologies.</p>

<p>My question is: Where do you draw the line as to developing a project in SharePoint versus Web/Winform application, and how do you convince your manager(s) that SharePoint may not be the best solution for a particular project?</p>

I sort of agree with you that this is sometimes a tough question.  In general, though, I agree with the cliche that you just have to think about a sharepoint app a little differently.  If your data can be considered as list-based, then SharePoint probably isn't a necessarily bad development framework.  It may seem like more work on the surface, but IMO the challenges just move from one place to another.  If you use things like custom field templates and web parts, you can relatively naturally handle all sorts of data.  And you get the positive aspects of SharePoint for free (an already mature security framework, built-in searching, site and list templates/definitions, personalized page customizations, yada, yada).
I also I don't know what you mean by "complexity and interactions with other technologies" here, so it's hard to imagine what specific issues might be introduced when SharePoint is added to the mix.
If your dev team is relatively inexperienced with SharePoint and you care about quality and deadlines, I can definitely see your point.  It's not an easy learning curve, but I think the SharePoint product is more naturally extensible than many people give it credit for.