Sean, you are both correct and incorrect!
Ordinarily, when you muck around with the contact list (which includes changing Sort Order or Filters) then a recycle is required for the changes to be picked up. This is down to the way the Recycle Table works. In essence, it is an index of all the callable records in the order they are to be called. One of the (main) things a recycle does is to repopulate that table. As a result, if you add records to the Contact List, they won't be referenced in the Recycle Table and therefore won't be called until after the next recycle. (Since both the Filter and the Sort are also part of the process that populates the Recycle Table, the effects of changing them are also not seen until the next recycle.)
That is the "You are correct" part ;)
JIT / Priority dialing was created, in part, to avoid this issue. There is a second table (the JIT table) which performs a similar function to the Recycle Table, however it contains records that have been inserted with a status of "J" and, rather than relying on a recycle, it is populated by a DB trigger that is executed whenever records are inserted and which is checked periodically (the frequency can be specified in the campaign settings) and anything found there is dialed ahead of anything in the Recycle Table. As a result, no recycle is required for the records to be detected.
That is the "You are incorrect" part :D
The upshot of this is that JIT / Priority dialing relies on triggers set for inserts. (As an aside, it is worth mentioning that changing an existing record's status to "J" will not work since the trigger is only on an insert. I don't know with 100% certainty, but I am 99.9% sure that this is due to performance. Dialer itself doesn't insert into the table much (if at all!) but it does update it. A LOT. Having a trigger on an update would probably destroy the DB server performance.) As you say, it all depends upon how the records are being inserted as to whether the trigger gets fired. I wasn't aware that the bulk insert avoided the trigger, but now I think about it, that makes complete sense. Since such triggers fire on a "per record" basis, if you inserted, say, 10000 records then that's 10000 executions and possible performance issues! As I mentioned previously, from what I have seen, most people using JIT are doing so as part of a system that has a back-end that inserts odd records (say, from a web page) so this isn't an issue. If it is causing problems (as in this case) then Support (and then Development) need to know. It could be as simple as having a second SP that runs after a bulk insert that checks all the new records for status of "J" and updates the JIT table accordingly. This would probably need to be an option, though, since for those folks who are updating the contact table with large record sets through IA and NOT expecting JIT, you wouldn't want to hit performance! (A classic case of you can please some of the people some of the time...)
Anyway, the upshot of all this is that it looks like the system is behaving as expected / designed and the OP will need to investigate other ways to achieve their specific requirement.