Choosing a framework is quite important and binding decision, which is difficult to change later. This decision will significantly affect the development of the application, as well as its future maintenance costs. Do we have to make it for sure? I have been developing projects with and without frameworks. Now for some time I develop applications without frameworks, and you know what? - it's not so complicated at all. You can feel a lot of lightness and flexibility in your application. Generally speaking, an application that does not use the framework is more independent, and I will try to explain this below.

Without framework Team is more focused on good architecture

Framework does some work for you, you can not control fully the application architecture - part of architecture is provided by your framework, so before selecting right framework you need to know them to see how it will affect your application. When you resign from using the framework, you take control over the application architecture. Doing this for the first time may seem complicated, but simple is better. Just split your application into modules (here HTTP server, here message queue, here database connection provider, and here business modules 1 and 2). I will probably mention more about my approach to the business application architecture in the future.

Application may run faster and use less memory

Usually software frameworks add some additional memory footprint to your application. This is not a big problem - unless you want to create compact and fast applications (such as microservices), and you don't create applications in a language compiled during application runtime (like Java). Without a framework, you will definitely be able to make an application that starts faster and uses less resources, because you won't need all those advanced mechanisms that are in frameworks to handle various extreme cases in other applications.

Tip: Code without a framework is more portable to other projects and use cases.

You don't have to spend your time learning and understanding new framework

… and I can code instead. This is weak argument, but I just want to mention here that frameworks are created (among others) to speed up our work. This acceleration is usually only visible at the beginning of the project, where you can very quickly show something working. With the growth of the application you need to look deeper and deeper inside the framework in order to better understand its operation, keep its performance, create custom solutions that were not planned by the authors of the framework. Framework are usually easy to start and hard to master, but this knowledge is not necessary to make good applications (when you are not using frameworks).

You don't have to fight with framework "magic" during debug

In my application usually I don't need all this "magic", I can just simply write myself this paths between libraries and business logic. When I see troubles or implement custom solution, I don't need debug through framework layers and abstractions - It's my code and I have control over it.

Team is more free to do changes in technology used in application

When working on an application, you are not limited to the technology that is supported by your framework. The application can evolve more easily and gradually, because you will not come across the limitations and lack of support for a given solution from the framework you use in the project.

Less worries, when you need to update application libraries

Simple test - take a piece of code from application created 5 years ago that uses the framework and one that does not. With which code you will have fewer problems to run? The truth is that frameworks lose compatibility with older technologies very quickly - updating frameworks often ends up with migration of code for a large part of applications. Adoption of new technologies is also much slower - there can be a new technology that you would like to use in the project, but your framework does not support it yet.

Framework may be discontinued

Another of the risks (especially for smaller frameworks) is the risk of abandonment by authors, or slowed down development. There is a good chance that your software will work for years, but you can't be sure that the chosen framework will still be actively developed and that suddenly you will not have to pay the unnecessary cost of resignation from that framework and/or switching to another one.

Summary

You could probably say "but the same problems also apply to ordinary libraries" and you're right here, but libraries are not so tightly related to your application like frameworks - they are easier to replace.

Don't misunderstand me - frameworks are not evil. However, before deciding to add them to your project, it's worth considering whether it's really worth using them in terms of the project's lifetime. Currently I have a feeling that the developers are not considering whether it is worth using the framework or not, but rather which one to use. In many cases the best solution will probably be to not using any framework.

But there is a risk...

I have in my mind a certain risk related to not using any framework in the project - it may lead to the situation that developers start to write their own framework, which will be used in many projects in the company. This is also not a good solution - because we will slowly fall into the same problems, and additionally we will have to maintain the code of the framework ourselves. When developing applications, I recommend to create and use libraries that are loosely related to each other and with the project, so that they are easier to replace and unnecessary functionality is not added to the project code.