keeping max messages in high priority thread

Hi Florent.
I'll try to answer some of your questions:

can I assume that integers coming out of transport’s second outlet (beats) are in the high priority thread?"

Yes

if I work in Audio In Interrupt and these integers are in high priority, am I correct to assume that their precision is related to my signal vector size?"

Yes, as long as you have the audio on.

is the high priority thread object-to-object based? For example [toggle > metro > counter > dial] would be [low / high / low / low]? Or does it mean the whole chain is in high priority?

toggle, if clicked, outputs a message in the main (low priority) thread.
metro outputs messages in the scheduler (high priority) thread.
counter outputs numbers in the thread of the messages it receives. So, in this example, it will output messages in the scheduler thread. This is the general rule for most Max objects. Indeed, under the hood, mouse and keyboard actions translate as messages coming in the main thread, so the toggle above is no exception. On the other hand, there are exceptions.
dial follows the same rule: in this example, since it receives numbers in the scheduler thread, it will also output them in the scheduler thread. On the other hand, all the Max objects are drawn in the main thread, but this doesn't affect the way they output messages.

what is the best way to trigger a max message and be sure it’s in high priority? Add delay after each object? Add delay only once?

See above, and also keep in mind that:
All the MIDI interactions happen in the scheduler thread
All the mouse and keyboard interactions happen in the main thread
All the file operations happen in the main thread, so if for any reason you need a message triggered by a file operation to be moved to the scheduler thread, you will need to delay it. Also, file operations are moved at the tail of the main thread queue, as with deferlow.
All the messages related to the audio thread (see e.g. snapshot~, edge~) happen in the scheduler thread
Some specific objects (defer, deferlow, jit.qball, qmetro -- am I forgetting something?), and all the Jitter objects, always output messages in the main thread.
So, there is no simple answer. Still, I’d say that in general you don’t need a delay after each object.

are the four following examples similar? And am I correct in the priority levels?

No. All the final bangs happen in the scheduler thread -- which, since you switch SIAI on, coincides with the audio thread. Still, I don’t think that the comment “High priority” beside the phasor~ makes much sense.

Are [snapshot~ 1 > speedlim 200], [snapshot~ 200} and {qmetro 200 > snapshot~] equivalent in terms of data rate reduction?

It seems to me that, although the results can be pretty similar, or probably identical in most cases, the three examples are not strictly equivalent. But I’d have to give them more thought...

Hope this helps
aa