Nostromo was developed when convention over configuration was the way to go. This means that as long as classes, directory structures and other things conform to a certain convention the framework will pick them up automatically. While this enables a very fast dev flow when you are used to the conventions, it slows down anyone that is not fluid with them, resulting in a quite steep learning curve. Over time explicit configuration came en vogue again, because it is easier to test as certain aspects of the application flow can be easier mocked during testing if you are able to overrule the default. As time went by both approaches mixed in Nostromo, which makes it quite hard to understand, when something just works automagically takes some getting used to which parts work by convention and when you have to configure stuff. We started to be more explicit and make more use of concepts like composition over inheritence, resulting in more explicit and concise code in newer parts of the framework.
Nostromo started when Symfony was in its early stages and the predominant PHP framework was CakePHP. The quality of available frameworks was just lightyears behind stuff like MVVM Lite for C# or Ruby on Rails. This (and the component based UI ) was the reason to start our own framework. In recent years we tried to decouple Nostromo much more and exchange parts of our own code with community standards like Monolog or Symfony Debug. Over the long run we wll migrate to Symfony or Laravel. Migration to Symfony will be much easier as it is not as opinionated as Laravel. The UI is build in a component-based manner similar to how you build UIs for desktop applications (i.e. Swing). You build object trees that are only rendered to HTML at the very last moment before the output. This enables us to create UIs programmatically and have different output by using another rendering method for that object tree. It takes some getting used to, because you rarely see any HTML and if you do it just looks weird and out of place because you have to switch concepts with these mixins. In the long run we will probably switch to view models and use libraries like inertia.js to connect single page apps with our server side logic.