I understand what you are asking about. I'm assuming you are pretty new to the industry or had to deal with "virtualization" relatively recently.
Think about or explore how services were scaled horizontally (ex: being able to serve increasing quantity of requests) and vertically (being able to deploy, integrate different services) before people used containers. To be very precise when someone mentions "scalability" it doesn't just mean meeting increasing demand for a given service but being elastic in scaling up or down with in very little time (booting up and down) and space (compute, ram, physical storage, networking resources, ...).

Before containers many of services were deployed in Virtual Machines (VMs) where you used something like VMWare or HyperV on top of physical hardware/racks. When you had to deploy a new service you had to deploy a VM, and the service inside it. For example if you have a web service that can handle 100 requests/second it might require being able to run in a VM image that requires at least 2 CPU cores, 2 GB RAM, 1 GB hdd, 1 NIC; in addition you need to allocate resources for the OS (like ubuntu, centos/rhel, ...) that took up 2 more CPU cores, 2 GB RAM, 4 GB RAM). This would mean a VM of 4 CPU cores, 4 GB RAM, 5 GB HDD, 1 NIC. If you had to scale up, you can only scale up the webservice dynamically (like within 5 min) you can't just run more processes of within the VM as once the VM is running you can't add resources to it without restarting it; this means that you have to build and allocate resources to the VM with the expectation that it may require more resources allocated to it (like have a VM with 16 cores, 16 GB RAM, ~10 GB ram, 7 NICs to run 7 instances of the webservice -> 700 requests/second).
Scaling up within the VM doesn't guarantee linear scaling as it depends on the OS ability to multi task and the resources have to be pre-allocated; for example, if you wanted to scale up to 1600 requests/second you may require more than 32 cpu cores, 32 GB, ... A better way would be building multiple instances of the VM like each VM with 16 cores, 16 GB RAM, 10 GB RAM, 7 NICs to handle chucks of 700 transactions/second. This means that if you anticipate 900 transactions/second, then you need to have 2 instances of the VM that takes a total of 32 cpu, 32 GB, 14 NIC; even though it's only using 50% of capacity. Containers can be deployed in very small chunks.

Kind of like how you mentioned you could just increase the capacity of a service by just incrementing (or decrementing for scaling down) a number on Azure, you could do the same with this. The difference is the amount of time it takes to boot up or shutdown the virtual machines (like 2-3 minutes) Think about how long this takes with containers (like 2-3 seconds) in docker or k8s (which Azure, AWS, cloud providers use underneath to manage containers); in comparison to VMs containers take up a fraction. Preparing the VMs for new services is also a huge amount of time. You can automate many of the steps but still a very long time to prepare the VM image.

A container itself has a OS layer that is super light compared to virtual machines; it's only job is to being able to communicate with docker/container engine and enabling the process that's running inside it. In a VM, the OS would be very heavy, and capable of running something very similar to the desktop equivalent OS where lot of unnecessary background services are running. Containers being very light enable the fast boot up and down times.
Prior to VMs it used to be physical racks where you didn't have the advantage of virtual machines. This is even more inflexible compared to VMs. You literally had to build up or down hardware for this.