"Pre-shared key" is indeed a valid model, and simple, if you can pull it off. Asymmetric cryptography, with public and private keys, and certificates, was invented to solve the secret key distribution problem: in general, it is hard to ensure that all pairs of systems/people who must securely talk to each other actually share a secret value. In a client-server setup, where client and server are distinct machines, then a shared secret must necessarily have travelled from one machine to the other. Travelling secrets are "less secret". With asymmetric cryptography, only public values actually go over the wires; private keys can remain local through their complete life cycle, and that's usually a good idea.
Similarly, if client and server share the same secret value, then an attacker hijacking either machine learns the secret and can impersonate both. With asymmetric cryptography, an attacker who plunders the RAM or disk of the client can later on connect to the server and authenticate as a client, but cannot run a fake server which would fool the client.
These are reasons why a pre-shared key mechanism, though tempting (it is lighter on CPU, and involves none of the dreaded X.509/CA business), make in practice imply some weaknesses, depending on how the system is installed and maintained.
(Of course, in all of the above I suppose that you do not do anything stupid, such as having a shared "secret" between the server and 10000 clients; if 10000 clients know a "secret" then it no longer is a secret. Appropriate pre-shared key systems use a different key for each client-server pair. When the pre-shared key is a human-remembered secret, i.e. a password, then extra care must be employed, because passwords are weak; this can be managed with SRP.)