What tag firing priority does
When several tags are attached to the same event, Google Tag Manager has to start them in some order. Firing priority is the number that decides it. Every tag begins with a priority of zero; a higher number starts sooner, and negative numbers are allowed for tags you deliberately want to go last.
The important limit is in the word start. Priority sets the order in which tags are launched. It does not make one tag wait for another to finish, so a tag that starts first can easily complete after a tag that started later, particularly if it has to fetch something over the network.
Why it matters
Priority is worth setting for the small number of tags that prepare the ground for everything else — a consent decision, a script that assembles values for other tags to read, a container-wide configuration. Giving those a head start reduces the chance that a measurement tag runs before the information it needs exists.
The gap between tags is measured in fractions of a second, which is why this rarely shows up during testing on a good office connection. On a mid-range phone on a mobile network, the same page can behave quite differently, and that is how most visitors in Nepal will see your site.
Where firing priority goes wrong
The main error is expecting a guarantee it does not give. If a tag genuinely cannot run until another has completed, priority will not deliver that; the pair needs tag sequencing, which does wait. Accounts where an intermittent bug was met by nudging priority numbers usually still have the bug, now with an extra layer of confusion on top.
The second error is inflation. Once a few tags carry a priority, people add more, and eventually every tag has one. At that point the numbers say nothing — if everything is important, the ordering is arbitrary again. A related nuisance is copying a container between sites and carrying over priorities that were set for a page structure that no longer exists.
How to use it well
Leave the great majority of tags at the default and reserve a raised priority for the handful that must go first. Use widely spaced numbers rather than consecutive ones, so a new tag can be slotted between two existing ones later without renumbering everything, and note in the container version description why each priority was set.
Then verify. In Preview mode the debug panel lists tags in the order they fired for each event, which is the only reliable check that your intention matched the outcome. If the order still is not right, the problem is a dependency rather than a priority, and it belongs in sequencing or in a proper data layer push from the site itself.