I think you are redefining scalability here. Tight development/ deployment cycle is just that, it is not scalability. Availability of the service shouldn't be dependent on how fast you can deliver new versions of the application.
You do need scalability as a fundamental component in availability.
Release cadances are important toward maintaining stability and vulnerabilities. Without a maintained application you lose availability.
You are still asking where does scalability fall in? There are several points for building a scalable system.
One is a design on load. So if you work on a ruby application you will know that typically unicorn is single threaded unless you want to do something like sidecart nginx. Not always the best.
Going toward infrastructure with a ruby system. Someone might say oh lets stand up an instance let puppet manage it.
This is where someone just decided to use an orchestration system that typically supports ruby. The flaw in this is that if you are leverage a non-binary deploy and forcing the need to use gems at setup on an application you create a massive potential for drift to exist across your instances.
Suddenly you say I will use ansible to run scripts to verify the host and applications run and that they didn't lose coherency.
The flaw with this is that you just overly complicated your system and likely dug yourself a mile of tech debt.
What you would use is a scalable system be it lambda or containerized solution liek kubernetes.
One of the biggest wins is speed and deploy cycles too. Kubernetes and lambdas are scalable solutions.
So as an application organically grows in load a scalable system will allow organic resizing on the basiss of demand ensuring that it maintains availability.
You should embed one reliability engineer on a team who can also code.
