ELM documentation indicates that this is not a query-only problem. I see on page 31 of that document that the issue was that of the rate at which J1850 requests arrive at the OBD system (this is a consequence of the April 2002 update of the J1979 standard). Specifically, they warn you against querying at rates higher than 100 milliseconds (also known as 10 per second) but don't provide any specifics.
It's important to understand that you aren't just passively reading data. There's a query-response asynchronous loop going on. As near as I can tell, too many queries too fast could overflow the outgoing message queue on the OBD system. Since that situation sounds an awful lot like a buffer overflow problem, it's not impossible that you could do fatal damage to your OBD system, if not your entire engine computer.
That's me being skittish: it's your vehicle, of course.
Now, that all said: it looks like OBD monitoring tools are freely available for Ubuntu. The manual page for obdgpslogger shows two options of interest:
Sample at most this many times a second. The software will sleep
temporarily at the end of each loop if appropriate. Keep in mind
there is an upper limit to samplerate, typically capped by I/O
on your serial port. Set this to zero to sample as fast as
possible. BE WARNED. Values greater than ten here are forbidden
for cars predating April 2002. If you think your car postdates
early 2002, and you'd like to sample as fast as possible, the -o
option may help
Enable certain elm327 optimisations. This will [usually] make
sampling faster [not a noticeable amount if you're only sampling
once a second], but makes it much easier to accidentally disobey
the standard if you're sampling as fast as possible.
From that page, it seems that the best actual rate that you're likely to achieve will result from:
obdgpslogger --samplerate 10 --enable-optimisations