I can’t count the number of times where an “architect” has evolved their own custom framework because they thought their problem was a special snowflake. It’s usually worse, less document and less tested than the popular alternative.
Are you asserting that developing an understanding for a vanilla web codebase is somehow worse than figuring out how to upgrade an Angular2 project to Angular8?
The biggest reason we use "custom" framework is because all the "standard" frameworks change too rapidly to support our business model. They also fall out of support before our B2B contracts expire, creating very difficult situations at due diligence time. We sell software to banks, so we don't get much room to work with regarding our 3rd parties.
That depends on the details of the vanilla web codebase no? There's no bright line between "vanilla web" and "custom in-house Angular-like framework we created from scratch that stymies new developers." It's all a matter of how the vanilla codebase is developed.
(but sure there are certainly reasons to do something without a pre-built framework, especially if you have certain support commitments)
See also: custom ORM, custom logging framework, custom authentication, etc.
1) far more likely that you have undiscovered vulnerabilities in it,
2) actually a lot more work to keep it up to date and properly secured over time, since it's all up to your team (and this becomes exponentially harder with every 3rd party lib that you use).
Not implying it's the case with your company, of course, but most of B2B companies that I've seen that use custom frameworks solve these 2 problems by simply ignoring them and not updating anything - hoping for the best and relying primarily on security through obscurity for protection.
That's often true, but the situation is not much different to framework stagnation.
"Popular" frontend frameworks I have worked with throughout the years, which are all more or less obsolete now:
Dojo, KnockoutJS, ExtJS, Backbone.JS, AngularJS, Angular 2+, Ionic
Web frontends are replaced every couple of years, often triggered by new feature development using the shiny new framework, and the cost of supporting the old, now unpopular framework.
Focusing on the actual web standards instead of another framework abstraction has long term value. For example, being able to query a DB using SQL is as relevant as it was 30 years ago, despite the numerous ORM/QueryGenerators on top of it.