At work we do almost everything in Java and perl, but I wanted to build out a feature using PHP and sessions. Some peeps thought that it was a bad idea to try to do PHP sessions on our system, cause it's distributed to many servers. What would the specific problem be?
Persisting sessions across several servers (also known as session clustering) is a common problem for scaling web applications, and is not specific to PHP. PHP does offer several solutions to handle it, such as the Zend Platform (commercial application server), and Msession (extension).
You could also use a custom session save handler:
http://www.php.net/manual/en/function.session-set-save-handler.php
I haven't ever tried it, but with it you define your own save/read functions, so you can implement a database or a shared nfs backend without the need to install any extensions.
Also Msession, which was suggested by @Eran Galperin, looks very interesting as an alternative to the one I mentioned before.
The answer to your specific question, what would the problem be, lies in the fact that by default PHP stores its sessions in files on the filesystem. For a single webserver serving requests, this is not a problem because your session data will always be available. But what if you had two load-balanced webservers serving requests?
Imagine hitting the first webserver with a request, which creates your session file on its file system. Then, your next request hits the second webserver. The second webserver will of course not see the session file. To the user, you might log in to a website, and then suddenly be logged out.
This is not a problem specific to PHP, and is very common. The solution is to store session data in some common area. The most common method for this is to store session data either in a database accessible to all web servers, or some shared memory cache server like memcached.