Einstein's Razor applies for the general case, whether you're making a simple website or a massive multi-purpose applicaiton.
It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience
You'll likely find the simplified form far more quotable: Everything should be made as simple as possible, but no simpler.
When you are creating a new system and have the choice between two development models, always select the one which leaves the system simpler unless you have a compelling reason to introduce the complexity. This compelling reason should be documented in such a form as to make sense to whomever inherits your code.
Unfortunately, it sounds like your specific case is an existing system that has become more complex over time. This leads you into the opposite principle, specifically If it ain't broke, don't fix it. A system that works should be left as-is, until it either breaks or a replacement is ready.
The question as to when you should replace vs. simply continue on is a management one, and really comes down to the cost in actual or opportunity dollars spent to maintain the considerable technical debt you have in the old system against the cost it would take to design, develop, deploy, convert, and support a new system.