Any framework you use will have dependencies somewhere, especially when it comes to the database. When aiming for framework independence as much as possible, don't forget the Repository pattern. I think that works great with either of the development ideologies mentioned. It keeps the model on in the Repository class so the rest of the application can rely on a consistent API through the Repository. If your framework changes, or your storage engine changes, update the methods in your repository class and you're good to go. That's very simple to do in CI4.
I think people often confuse Dependency Injection with a Dependency Injection Container. You can use DI (to some extent or another) in any framework. Many frameworks will provide a DI Container, though, that does the behind-the-scenes magic of locating the class and inserting it for you. That's a convenient thing, for sure, but also ties you a framework whose DI container operates the same way the current one does. I think the CI4 solution, while not as magical, actually ties you to the framework less than a container, since it's just a simple class that holds functions that create the stuff for you. While a base Services class might have to be copied over and given a different namespace, it's a transparent class with few, if any, ties to the framework.
Controllers will very often be tied heavily into the framework. That is very difficult to get away from, but it does mean you can limit your direct framework dependence to the Controller in many cases, especially if you have layers, like Repositories, that insulate you from the model.
Which brings me to my last point about framework independence. You can never get away from dependence on the framework 100%. Even if you don't use one of the named frameworks and you build your own from packages loaded from Composer - you've just built your own framework that are dependent on. The best you can do is to find ways to help insulate your core code and help make changes simpler. That said - radical changes like moving from one framework to another are pretty uncommon in my experience and is going to be a painful experience no matter how much you insulate yourself. So maybe just get coding, do your best to insulate yourself with the knowledge you have currently, and get better each site you make until you have a set of patterns you and your team like and does what you need it to do.
