First of all, software architecture is no exact science. Different gameservers use different architectures. So this answer represents how I implement tick-based gameservers.
Yes, message queues are very common in client-server game programming. Usually all the messages from clients get put into a queue which is then read while processing a game tick.
Game ticks are usually processed by some form of timer system. For example, when a server runs at 50 ticks per second, then there is a timer which will process a tick every 20ms.
When a server processes a tick, then it usually empties its message queue completely. Processing it just partially usually makes little sense and might overcomplicate a lot of things. The messages processing is also very rarely the bottleneck. The bottleneck is simulating the game. Update the positions of characters (when there is no message, then player-characters usually keep moving in the same direction they did in the past tick), update the trajectories of projectiles, check for collisions, do path-finding for AI agents and so on. All of that needs to happen regardless of how much the players are doing right now. So it's largely independent of how much messages there were to process this tick.
Yes, when there is a lot going on in the game, then it can occasionally happen that the server takes so long to calculate a tick that it should have already started processing the next one. In that case you process the next tick immediately after completing the current one, hoping it will take less time and let the server catch up. But when the load persists, then the server might start to lag behind more and more. In that case you usually start to skip ticks in order to catch up.