Is there a problem with using a single SSL certificate for both SSL/TLS/HTTPS communication as well as to sign (external) digital timestamp certificates? Other than the obvious: if one key is compromised then both functions can be compromised as well. However, if I devise a secure method of handling keys, and also use them on the same system, then both keys should be handled the same way anyhow and would end up getting compromsied together.
Technically, there's nothing prohibiting you from using a certificate for multiple purposes. A correctly implemented client should check the certificate's key usage and basic constraints extension values to determine if it is allowed to be used for the purpose that it's being presented for, but a certificate can certainly be created to serve two purposes.
That said, should you do this? Almost absolutely not. When you have two systems with very different security requirements such as these, it's not just a matter of "if one is compromised, they both are" but also that the system that needs the strongest security is exposed to the vulnerabilities of the system that requires the weakest protection. So, you either have to waste resources protecting the weaker system beyond its requirements, or unnecessarily exposing the system that requires stronger security and accepting unnecessary risk.
An example: Take a CA that uses their root CA cert as their web server cert. If they were susceptible to Heartbleed, not only would they have to deal with the revoking and re-issuing a server cert, a mere annoyance, but their extremely precious root cert private key would have been exposed, and potentially used to create wide-spread havoc which could be truly disastrous.
So, when you have systems with widely disparate security requirements, doesn't share certs (or critically limiting infrastructure) between them.