Is TEA suitable for encrypting/authenticating many short messages?
The main reason for using encryption is not so much secrecy, but authentication and protection against interference.

In that case, what you want is an authenticated encryption scheme.  While TEA, as a block cipher, may be used to implement such a scheme by using it in some suitable AE mode (such as SIV), there are also a number of dedicated lightweight authenticated encryption schemes that you may wish to look into.
In particular, I'd suggest taking a look at Ascon, which was selected as the primary choice for the use case 1 (lightweight authenticated encryption) in the final round of the CAESAR competition last year.  While not quite as simple as TEA, the reference implementation isn't all that complicated.

Since your message length is fixed and very short, you could obtain a simple authenticated encryption scheme just by using a block cipher with a block size longer than your message length, padding your messages up to the block size e.g. with zero bytes, encrypting the padded message directly with the raw block cipher (i.e. in &quot;ECB mode&quot;) and verifying the correctness of the padding after decryption.
However, for this you'd want a block cipher with a block size of (at least) 128 bits (= 16 bytes), which TEA doesn't have.  XXTEA could work, though.
With 4 bytes of padding, the odds of an attacker randomly guessing a valid ciphertext would be 1/232 per attempt, which seems likely to be low enough for your purposes.  This would be a deterministic encryption scheme, so it would leak whether or not two plaintexts are equal, but that shouldn't be an issue for you since your messages include presumably unique timestamps anyway.

As for the security of TEA or other crypto primitives for your purposes, the first thing I'd like to note is that it seems extremely unlikely that anyone would develop and implement a novel cryptanalytic attack just to interfere with your system.  Thus, you should be fine as long as the scheme you're using:

has withstood any serious cryptanalysis at all (i.e. it's not just some random homebrew cipher kludged together by someone with no crypto experience),
has no known practical attacks (i.e. with complexity well under 264 or so operations) with published attack code that someone could just download and run, and
the way you're using it isn't broken in some way that would allow someone to bypass the actual cipher entirely.

In fact, you might be fine even if one or more of the above happened to be false, as long as none of your potential opponents has the skills or motivation to analyze your scheme and develop an attack against it.  But as long as you're using a cipher with no simple practical attacks, and use it correctly, you should be safe even if someone with some crypto skills does decide to try to attack your system.
Honestly, your biggest weakness is likely to be the last point.  That's how most cryptosystems get broken in practice — not by breaking the underlying ciphers or other crypto primitives, but by finding bugs or design flaws in the way they're used.
To give a simple analogy, the strongest lock on your door won't help if you leave a window open or leave the key under your doormat.  With crypto, as with physical security, the whole system is only as secure as its weakest link.  And the weakest link in your system is almost certainly not the block cipher, whether it's TEA or AES.