Oracle switched from Waterfall development model to sprint years ago. They also switched from yearly to quarterly releases (for their Apps) which means they deliver a lot of features in a year.
Without commenting on whether this is true of Oracle, that conclusion doesn't inherently follow from the given. If I'm driving 60 miles per hour, then recalculate it in miles per minute, that doesn't actually mean I'm going faster. Oracle could easily be delivering 1/8 a year's worth of features in 1/4 a year due to release process overhead for all I'd know.
This is also the same incentives that resulted in many classic architectures from 80s and 90s relying heavily on stored procedures. It was the only place where certain data could be crunched in a performant way. Middleware servers lacked the CPU and memory to crunch large datasets, and the network was more of a performance bottleneck.
I’ve had this argument with several DBAs. They always claim “Oracle is the most performant,” while quite possibly true technically, they also tend to run a single massive instance that inevitably leads to a complete failure of the site under heavy load. Oracle is often designed to be the single point of failure. I believe that is by design. The same problems can be solved with modern event driven architectures, better caching, horizontal dynamic scaling, etc.