It depends on what your requirements are. In general, it is accepted that an observer knows when meaningful data is exchanged - even if he can't read it - because, well, we simply don't care. But in some cases this may be unacceptable, such as in p2p protocols where anonymity is very desirable and a fuzzy network can add a decent amount of secrecy.
On the other hand, continuously streaming is quite heavyweight, as it is in general not possible to keep streaming indefinitely (and intercepting all the garbage data and interpreting it as meaningless probably isn't free either, although that depends on your transmission protocol).
or sending encrypted pseudo-random data
Huh? Why would you encrypt pseudorandom data? This is actually a bad idea - by doing that and encrypting your pseudorandom stream with the same key, you will have tainted all the garbage data with your key material - the same key used to encrypt your precious ciphertext - thereby giving the attacker orders of magnitude more stuff to work with. If the underlying pseudorandom data that you originally encrypted is broken, boom, you just gave your opponent lots of plaintext/ciphertext pairs, and your key (and therefore, your ciphertext) is now potentially compromised.
No, just send pseudorandom data that's independent of all other information you might rely on, so just grab a few hundred bits of entropy and run some cipher in CTR mode or something to produce a nice pseudorandom bitstream - this way, even if this part of your scheme is broken, your ciphertext remains safe (even if the attacker now knows its size and roughly when it was sent).
but otherwise adds the risk of a Known-plaintext attack should the
garbage-generator (or the way separating actual message) be predicted.
How so? If your cryptography is sound, and the garbage data does not leak any information about the plaintext or any key material (which it shouldn't, since it's just random bits), the two methods should provide equally optimal privacy. Even if an attacker somehow managed to distinguish the relevant ciphertext, he still wouldn't be able to decrypt it.
Does the answer also depend on whether the messages shall be secure
"forever" or if it is sufficient to maintain secrecy for a limited
amount of time?
Again, it depends on your requirements. There is no "one size fits all" cryptography, and every application needs its own version of it, that's why there are so many different protocols and schemes around. You need to figure out yours and implement it.
So basically, define your use of the word "secure" in your first sentence. Secure against what, and how secure should it be (should it provide only privacy? privacy and anonymity? perhaps integrity too, what about authenticity? etc...)