Salting a password is only used to prevent rainbow attacks
That's not entirely correct; for one you could easily distinguish identical passwords if there is no salt (or other data) used to distinguish between use cases or indeed users.
Using a high number of rounds is only used to prevent brute-forcing short passwords
Well, yes. A normal hash is already one-way, and you need the salt for the aforementioned purposes. So the only reason to use the iteration count or work factor is to have the attacker perform many rounds of the underlying primitive as well.
Of course, if the salt is missing, the iteration count would also make it harder to build a rainbow table.
But if a password is computer generated and only used in an automated way between 2 remote systems, is it safe to salt it, but not hash it with multiple rounds?
That's not a password, that's a secret. If you'd use it correctly you might not even need a salt, although you will have to keep in mind that the secret remains the same in the protocol that you use it for (e.g. for encryption you'd need an IV or nonce to make sure the outcome is not deterministic).
Would using an extra long randomly generated password (like a 256 bit password) be enough to avoid needing the multiple rounds?
There is no such thing as a 256 bit password. Passwords consist of text, not binary. 256 random bits are common for keys such as AES-256 keys or keys used for HMAC-256.
A password could have 256 bits of entropy, spread over many characters. But such a password could not be remembered by a human for normal operations. For instance, if you'd use ASCII with all possible special characters (without space) then you'd need a fully random 39 character password ($\log_{92}(2^{256})$ in case you want to verify this).
And yes, for a secret key you would not need the iteration count or the PBKDF in the first place. If you need a salt or not depends on how you are going to use it. You would not need it for one-time usage. If you need a KDF then you could use a Key Based KDF such as HKDF.
