PHP is by nature non persistent language. You share nothing between requests.
Persistency is always managed outside, i.e. session are handled by cookies on communication, loading a persistency session storage (usually a file, but it's a database storage for Drupal). And the content of the application is on a database, files, etc..
With PHP you cannot make a persistent server, reusing objects for several requests. Well in fact you could try it now with some advanced usages of PHP, but it is not the nature of the language, it's not built for that. Everything has to be loaded first, and everything is killed after the end of the request handling.
So all PHP CMS or frameworks, and Drupal is one of them, are built to handle this fact in a clever way. And the main strategy for that is to speed up the time of environment rebuilding with caches (as always, manage persitency outside PHP). To manage high load applications with Drupal you'll have to tweak the cache management:
- activate caching (of course)
- use several layers of cache, like for example APC for some classes and path caches, memcache or mongodb for some other caches, MySQL (the default) for others, etc. You could also use modules like Session proxy or others to dispatch your session management on a redis server, or mongodb, memcache, redis, etc
- use a reverse proxy cache like varnish to manage public pages caches, or even page parts with varnish ESI.
If you compare this to persistent application servers like java or C# can produce it seems to be a bad point. But sometime early constraints help developpers in finding better ways of doing things (I'm not saying Drupal always use the best ways of doing things :-) ). And a lot of heavy load websites use PHP (with caches). So it is just a different way of doing websites.