There are several things that could be going on. First off, how are you determining if a job is a top job? A job in the higher priority queue isn't necessarily a top job. It's only if the job is one of the first 10 jobs in that queue that makes it a top job. If you look in the log, there is a message emitted when a job becomes a top job.
Two top jobs will not cause one of them to be pushed later in the calendar. The only way this happens is if a filler job is run on the same resources as a top job and extends into the top job's time. By the nature of being a top job, it can't run now. Even if two top jobs were added to same resources at the same time, that would only stop other jobs from running right now. They wouldn't cause harm to each other.
The likely culprit is your complex backfill_depth/queue setup. Top jobs do not receive a reservation in the PBS sense (see advance reservations). The scheduler adds top jobs to the calendar each scheduling cycle. The scheduler will always take the first N highest priority jobs and add them to the calendar. If the same N jobs are the highest priority from one cycle to the next, all is good. If the ordering of the highest priority jobs changes, then a different N jobs will be added to the calendar. The bottom of the list in the previous cycle will be bumped off and new ones will be added on.
You have several things working against you in your setup. First is fairshare. This can easily change which is the most deserving job per cycle. If the highest priority job's entity has currently running jobs, each cycle those currently running jobs receive lowers the priority of the high priority job.
Another idea is that one queue could reach its limit of 10 top jobs while other queues haven't. This means that you'll add some top jobs to the calendar, skip over others, and add more from another queue. Consider the following: J1 is from Q1, J2 is from Q2, J3 is from Q1. We add J1 to the calendar. Q2 is at it's limit of 10 top jobs, so we don't add J2 the calendar, J3 is added to the calendar. The following cycle we have the same ordering, but J2 can run. J3 hasn't been added to the calendar yet by the time J2 runs (since J2 is higher priority), so J3 gets delayed. If this is the case, consider removing your backfill_depth per queue and adding a larger backfill_depth to the server.
Maybe an endless series of higher priority jobs are being submitted between scheduling cycles. These jobs could either run (similar to above) or bump the Nth job of the list. It might not even be an endless series. A single job can be very damaging to a large top job. The scheduler can take a long time collecting resources for that large top job. If the large job isn't a top job for one cycle, all those resources can be given away and the scheduler has to start over.
Maybe jobs are starving? Once a job starves, it will gain priority over non-starving jobs (even in higher priority queues). If you don't want this behavior, turn help_starving_jobs=false.
Lastly, what do you mean by high priority queue? If your high priority queue has a priority of greater than 150, it is an express queue. These jobs get the highest priority over all other sorting methods. It also means you'll start preempting. You'd would have noticed preemption, so this isn't likely the case.