Stunnel is SSL and, in SSL, private keys never need to travel. The "SSL ethos" is that X.509 certificates are used to authenticate peers without a pre-distributed shared secret. For example, when you connect your Web browser to
https://example.com, the SSL layer recognizes the server certificate and can make sure that it talks to the real "example.com" without needing prior knowledge about that specific site.
Stunnel is out of this model, since it is typically used between two machines that already know each other. This allows lighter models to be used.
By default, stunnel does not validate certificates. This is stated as so in the HOWTO page (in the "How does stunnel check certificates?" section). If you did not change that setting, then it does not matter at all what certificates you use. Of course, not validating certificates leaves the tunnel vulnerable to Man-in-the-Middle attacks. This can still be acceptable, from a security point of view, if the tunnel is meant to convey only an underlying protocol that already includes cryptographic protection; typically, you use stunnel to get through a school/company firewall, but inside you just run some SSH. The stunnel is there only to keep the firewall unwary of the SSHish nature of the communication. In that specific case, not validating certificates is fine. (Well, fine with regards to your security. You are still circumventing your school/company firewall, which is morally and legally questionable.)
Most stunnel guides explain how to configure stunnel in that no-verification mode, and copying the certificate on both client and server is the most expedient way to keep things running.
If you configure stunnel to validate certificates, then:
The client must be able to check that the server's certificate (the certificate is the public part, NOT the private key), which entails either knowing it beforehand, or verifying its signature with regards to a known CA.
When the client has verified that the server's certificate is genuine, it must still check that it is the certificate of the intended server.
If the server requests a certificate from the client, it must similarly be able to verify it, and check that it corresponds to an allowed client.
There is no code in stunnel that compares the client and server certificates with each other. They really live in distinct worlds; the client certificate is validated on the server, the server certificate is validated on the client. Having the same certificate on both systems has no influence whatsoever on the behaviour of either.
In a certificate-check system, if both the client and server use the same certificate, then the client may impersonate the server, and vice versa. If there are only two machines, then this does not matter much. If there are more machines (e.g. two clients to connect on the same server) then this can matter a lot (you do not necessarily want to allow a client to frame another client with a fake server). And, of course, sharing the private key implies that the private key travelled from one machine to the other, which either used a preexisting tunnel (e.g. SSH), or was a risky operation. Private keys should remain private, and the more a private key travels, the less private it becomes.