There is a lot to unpack here. Let’s start with…
1. Security through obscurity
Obscurity in and of itself does not provide additional security, unless it is so utterly complete and total, that it barely balances being usable.
Are your company records secret?
Are you sure an attacker can’t find out who used to work for your devteam?
Are you sure none of ex- or current employees have any copies of the source code on their home machines?
Are you sure that they maintain secrecy and will not spill the beans willingly upon social engineering attempt?
Is your server running an OS that has no vulnerabilities?
Are you absolutely sure an attacker can’t get access directly to the server physically?
Is your team really THAT good and all the points of contact (which are exposed and therefore not obscured at all) in your framework are secure?
If you can’t answer a strong “YES” to every one of those questions (and many others), than obscurity is not going to help much.
Which brings us to…
2. More open means more secure
It is just a simple numbers game. There is a set percentage of security specialists amongst the population of developers in the world. If more people have access to your code—higher number of professionals will check it out and spot the problem.
This has been the working solution for pretty much every collaborative project in the past couple hundred years. That is how Wikipedia operates. And it is how most modern frameworks operate. They are open sourced in part due to security concerns. It allows them to prove that they are not hiding anything, and in turn, security professionals from all around the world have an opportunity to contribute their experience and skills to the creation of these frameworks.
The dedicated security solutions implemented in open source frameworks will beat you in terms of security. That is, unless you are absolutely sure that your team is able to achieve a world-class security in your custom-tailored closed-source project. Which brings me to…
3. Longevity of code
You have to rememember, that your framework is not floating through the void of space. Your code interacts with a lot of other systems.
You say that you use PHP5. It is now firmly in its “end of life” stage and will never be updated again. Are you comfortable using a system that has a bunch of well-known and widely publicized vulnerabilities? No matter how good your code is, and how strongly you obscure your system, those are not going anywhere.
When you say that PHP5 will still run on servers, do you imply that it will just work indefinitily? Because it most surely won’t. As the years go by, support for it will be dropped by major webservers, because there is no reason to drag all of this old, vulnerable, and barely used code along.
So unless you are going to keep your entire architecture the same for the next 50 years, your application is going to stop working as expected at some point. And if you do, then expect to have a lot more vulnerabilities to worry about.
4. Nothing lasts forever
It is difficult to tell what the web will be like in 5–10, let alone 50 years. Requirements will change. Your application will have to adapt. If your team can pull off writing an web application that will live for so long, using a closed-source framework, based on technologies that are already dying—hats off to you.