When you start a project and have a particular need, you have a choice:
When implementing your own solution, you introduce several risks:
The needs may evolve, requiring you to constantly write more and more code. Ultimately, the code you've originally written was never expected to be used in a specific way, and needs either a lot of refactoring or a plain rewrite.
Popular libraries and frameworks are designed in a way to cover much more needs than you have when you just start a project, which makes them look bloated at the beginning. However, as the requirements change, those libraries show their use by making you adapt their usage with ease, when they are designed well (and many Microsoft's frameworks are designed well).
Any new person who joins the project won't be familiar with your implementation. This makes it unnecessarily complex for the newcomers to start working on your code.
With popular libraries and frameworks, you don't have this problem. Either the new developer already knows the technology, or she doesn't, in which case, she has at her disposition a lot of in-depth, well-written documentation, a large set of Q&A on StackOverflow, training videos, etc. Developers themselves are usually more inclined to learn a popular technology than to spend a month trying to grasp YourMagnificentORM which, being proprietary, undocumented and poorly written, wouldn't give them any benefit when mentioned on a CV despite all its obvious qualities.
When using an existent library or framework, you introduce different risks:
The needs may evolve, and the library may not fit the new needs. This is especially important when the library is proprietary or when you're not inclined to contribute to an open source library.
The library/framework itself may lose its popularity (example: Silverlight) or the developers of the library may decide to take a course that doesn't fit your needs.
Both of those risks can be mitigated by a proper architecture where third-party code is abstracted from your business code.
seem to utilize all of the additional .NET framework libraries and code when they are not really needed [...] I am [...] talking about [...] full blown frameworks like ASP.NET Identity (and former iterations), OWIN, Entity Framework, MVC framework, etc.
What do you suggest to use instead?
If you want to implement OAuth authentication, you might re-implement OAuth protocol, although I'm not sure that spending a few months on that will really benefit your employer. Or you may just use the high quality code Microsoft developers provide you for free, and spend your time implementing actual features.
Owin gives you the ability to run your application outside IIS, given that the cost of using Owin in terms of code complexity is close to zero. If you are absolutely sure you will never ever host your application on anything other than IIS, and your team is unfamiliar with Owin and is not willing to learn it, there is indeed no reason to use it. Few teams are in this situation.
Entity Framework gives the ability to use a database to developers who are unfamiliar with SQL and databases in general. If you do have a skillful DBA in your team and if every member of the team has no issue writing SQL queries by hand, you don't need Entity Framework. Few teams are in this situation.
ASP.NET MVC makes it possible to structure your code using MVC architecture. Most developers find it superior to the architecture used by ASP.NET, leading to less code, less coupling, and proper abstractions. You get all those benefits for free (in terms of runtime performance), so the only reason not to do it is when you have a team of developers who absolutely love ASP.NET or when you need to maintain a legacy project which uses ASP.NET.
I laugh at OWIN actually being used by any serious business application; why would you use a social media login to anything that is supposed to be even remotely secure? These frameworks can only be useful for small (i.e. 3-5 pages) applications that are not really important or critical to businesses.
Owin has nothing to do with OAuth login.
Aside that, StackExchange family uses OAuth authentication, and it also uses ASP.NET MVC. Do you characterize those sites as “small 3-5 pages applications that are not really important or critical to businesses”?
What is the point of using these frameworks when they just introduce bloat, complexity, and over engineered code into projects?
The goal is exactly that: to reduce bloat, complexity and over-engineered code, by ensuring all the complex stuff is within those tested, reviewed libraries, and not your project. This is the code you don't have to read, maintain, document, review and test.
I could be missing something, but if I takes a few days to write a full database ORM structure and login logic using default classes that is lighter, faster, and more flexible versus using Microsoft frameworks why not?
Even properly documenting a basic ORM requires at least few months. A weekend ORM project may be fun to write at home, but I would hope you won't decide to use one in the projects which are “really important and critical to businesses.”
Do any of you actually use these frameworks in your own projects or enterprise level projects?
I work for one of the three largest European banks. We use OAuth to consistently provide SSO for every product. We use Owin, because most of the projects are hosted outside IIS. There are a lot of other Microsoft's libraries being used, which allows us to keep the code clean and maintainable, and focus on the features, instead of technical stuff such as the internals of WebSockets, REST or WebHooks. By spending a few hours or days learning how to use an existent library, we save a lot of time and money if we were writing all this stuff from scratch, and then constantly maintaining it. This is how businesses work.
You are, however, absolutely right when you talk about the feeling that simple projects are bloated. It is so easy to add a new package to a project, that many small projects tend to include the libraries they don't even use or at least don't need at their scale. Take CSS and JavaScript bundling and minification. For a starter project, there is little use to have one, but many tutorials present it as a default choice, transforming the whole system from opt-in to opt-out.
While those libraries rarely present a performance impact, they do however make the code more complex than it has to be. The same problem, by the way, exists in other communities; for instance, many Node.js apps I've seen tend to have way too much dependencies.
In .NET world, the culprit is not only the ease of adding libraries to a project, but also the fact that Microsoft promotes its ecosystem as something where you get "all the features you need," even if you don't necessarily need them.
"I laugh at OWIN actually being used by any serious business application"but I cannot think there's really any better way to write a RESTful service using .NET without reinventing the wheel.