Scaling an application's operation does not directly relate to its algorithm's efficiency, is my point. Of course a really inefficient application can eventually become unusable, but even terribly performing applications can be "worked around" and thus scaled higher.

Say your app is using bubble sort. Egads!!! What a shit design. Clearly this is going to become a nightmare in real world scenarios. But wait - we can theoretically get to O(n) if the list is already nearly sorted. How can we achieve this? By monkeying with the dataset, queueing and batching operations, invalidating operations that take too long, artificially limiting the number of requests per second, or just passing the request to a completely different app depending on use case. It sounds insane, but if you can perform any of these things quicker than redesigning your app, so that it can continue performing under load, that's an example of "scaling" despite the application's poor performance.

Another example is the "scalability" of application development. Say you have an application which is basically O(1), but one day you find a bug in it. Even after you write and commit the one-line fix for the bug, if it takes you between four hours and two days to deploy it to production, or the validation process takes a month... You still have a bug in production for hours, days, or weeks. "Scaling" the development process can significantly reduce the amount of time needed to solve problems, or complete new features. It can be more beneficial to be able to ship code faster and more reliably, even if it isn't the most efficient code.