Protocol versions matter, even given the same cipher suite, because the suite specifies the primitives but not necessarily how they are to be used. For example, the critical difference between SSLv3 and TLS1.0 that makes the former vulnerable to POODLE is that TLS mandates validation of the padding, and SSLv3 does not. TLS 1.1 requires an explicit initialization vector (rather than the implicit IV used in TLS1.0 block ciphers), and changes how padding errors are handled; neither of these things are particular to any given ciphers.
Of course, just because a protocol requires something doesn't mean the implementer will do it correctly. Some network gear (like load balancers) was handling TLS1.0 connections but failing to validate the padding (in violation of the TLS spec, but not the SSL spec), making them also vulnerable to POODLE. Similarly, one of the things that made Heartbleed so bad was that OpenSSL allowed heartbeat messages to be sent before the handshake was completed, allowing an untrusted attacker to man-in-the-middle a connection and attack both sides during the handshake. (Of course, the buffer over-read at the core of Heartbleed was also an implementation failure, but the standard probably doesn't explicitly called out that you're supposed to only return the data that the other side sent you instead of arbitrary memory. It does specify when a heartbeat message is legal, though.)
Protocol versions can also add support for cipher suites. TLS 1.2 added support for authenticated encryption ciphers, enabling the addition of suites based on AES-GCM and AES-CCM. However, even if you're using the same cipher suites, you're more at risk when the protocol is older.
For more detail, you might want to ask on the Crypto SE. SSL/TLS is complicated and you may find people over there who can explain the relevant pieces more clearly.