You seem to be equating frameworkless with library-less.
> a team that spent weeks on "given a certain event happens in the software, dispatch a notification to the user".
This is trivial without a framework as long as there is a library you can use to "notify the user" (e.g. an email or chat library). It's actually easier without a framework because "event" is just a line of code somewhere in your own application, while in a framework, it can mean a million things and maybe NOT what you actually wanted.
But libraries are much more effective in frameworks.
Say an event that shows a message to a user next time the user sees a page has to know about users, has to be able to store messages for users and remove them once they have been shown, it needs to know about i18n, and have tools to display the current messages in HTML.
A Django library for it can assume the existence of Django for all those things, a general library has a much harder time.
No, I'm not. Libraries were certainly used in this case.
But whereas in Rails this would be mixing in a library to a controller to allow events and configuring them, this was building a new set of models and code over the top of a library for something like Mailgun from no code. A two hour job in Rails/Django/Phoenix but a two week sprint long job to roll your own. Why bother?
> a team that spent weeks on "given a certain event happens in the software, dispatch a notification to the user".
This is trivial without a framework as long as there is a library you can use to "notify the user" (e.g. an email or chat library). It's actually easier without a framework because "event" is just a line of code somewhere in your own application, while in a framework, it can mean a million things and maybe NOT what you actually wanted.