They both hit the same challenges. The bottleneck with any web application is pretty much always the database, especially SQL ones where replication and sharding is not as easy as some other tech like MongoDB and ElasticSearch.

Both kbin and Lemmy use PostgreSQL, so they'll both hit similar bottlenecks.

Lemmy has the advantage of processing much faster thanks to its Rust backend, requiring less CPU, but PHP is also very easy to scale up to add more server and more compute to it. PHP has some advantages despite its reputation, in that it's pretty hard to have memory leaks like Lemmy experienced recently, because the whole process resets at a configurable amount of requests, and on the PHP side, each request is independent and starts over from scratch, making it hard to accumulate in-process state that doesn't get wiped out after each request. It also indirectly forces you to rely on external cache and queue services for synchronization, which can help prevent some gotchas that long running servers in Rust/C#/Go/NodeJS would. In a single process it's easy to turn to global state and hit gotchas when you have it running on two different servers.

But functionally, they're all capable of roughly the same, as the bottleneck will still be the database. Scaling databases is not easy, although not necessarily that crazy hard either.

Without any knowledge on the details of both implementations: scalability has two dimensions, vertical where one server can handle more requests and horizontal where more servers can be added to serve requests. In recent years focus has been put more on the latter and for that the performance of a single node isn't as important as for the vertical scalability.

Idk what the heck your talking about lol but lemmy is always up and for apps for it meanwhile kbin goes down and only has a PAW. I have an account in both but been using lemmy more. Using liftoff for iOS and its amazing!