For many modern web based businesses that practice continuous deployment and test-driven development, they may not have an explicit validation period where SQA and final validation is the focus. They could run entirely off of a test-driven software development process - and push sprint outcomes directly to production (as they can always roll back a change if needed)
For complex, high availability systems with service level agreements (i.e. systems that are mission critical that need to stay up), or for software that runs on custom hardware with a specific product release schedule and cadence, a validation period is absolutely critical to ensure that the product release is well characterized and thoroughly tested through major workflows (both positive and negative) before the product is released to end users.
Imaging releasing software that manages a nuclear power plant. Alternatively, imagine putting out a new software release on a robot that has the physical capabilities to seriously injury an end user if it malfunctions. Or imagine releasing software on a benchtop diagnostic device that detects cancer.
In this case a 2:1 to 5:1 ratio between elapsed development time and elapsed SQA time may be prudent. In general, the greater the risks (or the more highly regulated the sector), the longer one spends in SQA.
Special thanks: Martin Trust Centre, MIT
Edit: Javier Rojas, 15/04/20