It depends on your accuracy requirements. If you for some reason want to vary (or, see below, record the variation of) the sampling frequency, a timestamp on every sample will make things obvious. A failed sampling will stand out and offer you the possibility of interpolation while non-timestamped samples will hide and transport the error to the gap between packets, creating a temporal offset of up to "ptime" (borrowing the RTP syntax here again) in locating the error.
Also, it might be more desirable to describe the system latency of the measurement inside the sampling node by actually recording the time the sample was taken rather than assuming an
a priori sample interval. A perfectly clean signal sampled at irregular intervals will have time-domain issues when plotted/played back with a steady clock tick. If, OTOH, the sample time is recorded and sent on with the samples, the signal will come out just right if the interval is observed in the interpretation.
All of this of course assumes a good enough clock in the sampling node, in lockstep with the interpretating node at that. Clock jitter, measurement resolution requirements, CPU capacity in measurement, gathering, processing or presentation nodes might make all of this moot. YMMV, of course.
Sidenote: I once ran a DNS name server for our CC TLD. The domain registry wanted query statistics every 5 minutes reporting on the number of queries, with some detail on success, fail, error, etc. My name server was running "nsd" which is written with performance in mind, first and foremost. Signalling the daemon to dump statistics was done from "cron" every 5 minutes. However, the daemon deemed answering DNS queries more important, so statistics were dumped ASAP, not immediately. This was no problem, because the dump was time stamped to the required precision, recording the time it had been taken.
However, the PHP dude whose "code" was the recipient of the data had, to make things easier for himself, simply assumed 300 second intervals between readings. As a result of this clusterfuck-in-waiting, the graphs from my server were not as beautiful to behold as the graphs from other name servers where statistics dumps were treated as more important than answering queries.
The proposed solution? Said dude asked if it was possible to force my name server to adhere to the 300 second assumption, ignoring the actual task at hand, answering queries.

Naturally, we refused, and presented the resultant graphs from Doing The Right Thing.