Lots of reasons: - Software bloat leads to slow download times and slow launch times and more RAM usage - Abstraction layers often get out of control and sacr

Lots of reasons: - Software bloat leads to slow download times and slow launch times and more RAM usage - Abstraction layers often get out of control and sacrifice lots of performance and lead to software bloat - Often you start with and SDK thinking it will solve your problem, but it turns out it doesn't solve your exact casem which means you end up spending lots of time fighting the SDK which leads to a mess+abstrction+bloat. Many times you might have been better off writing it from scratch. - Dependency hell which brings in the bloat+abstraction problems. Plus now you now have extra environment and deployment headaches to make sure everybody involved has the correct dependency chain and correct versions of everything. - Build system hell: Once you have dependency hell, you often bring in build system hell to manage everything - SDKs (Frameworks) take control of everything: Often frameworks impose lots of rules and conventions that leak into everything else you do. This means following their design patterns, subclassing from their classes, etc. Their stuff may not fit well with your own stuff. Also, this often deeply entangles your stuff with their stuff so it is hard to remove later. - Fighting between SDKs: Lots of SDKs try take over the world. If you use multiple SDKs, they may fight. - Lack of understanding: People too eager to use SDKs often lack the understanding of how it works. To fix bugs, to fix performance problems, to extend features, means you must ultimately understand it, but often this comes too late in the process. And you discover that for all these things will require massive changes to the framework or a complete rewrite. You would have been better off writing it yourself in the first place or picking some other SDK that you understood better.