Introduction:
Slot battles occur when a slot has been assigned to be processed by more than one pool at a particular allotted time during the course of an epoch. In this answer, we want to provide a more in-depth discussion of the context and consequence of the occurrence of slot battles.
Slot Battles: a feature or anomaly of the Cardano network design?
From the outset, we need to understand that slot battles are a feature of the Cardano network protocol and not some anomalous error that has been inadvertently created whilst designing the protocol.
The Cardano network protocol has been designed to thwart the potential of DDOS (Distributed Denial Of Service) attacks. To that end, the engineering of the protocol meant that each network pool (also called "validator" in other blockchains) that gets assigned a schedule to process or validate blocks does so independently of the knowledge of any other pool's block processing schedule. A pool's schedule - also called a "leader log" - is a timestamped event where a pool is responsible for the processing of one of the slots (or blocks) to be added to the blockchain. Slots occur every second. On average a slot gets filled by a block every twenty seconds under the Cardano network protocol.
The allocation of leaders to produce blocks in slots for each pool that qualifies to process or validate blocks is determined via a lottery event using the Ouroboros Praos Proof-of-Stake VRF function.
The lottery event in conjunction with the VRF keys creates a potential universe of assignable slots to any pool as a function of the amount of ADA staked and pledged to that pool.
It occurs with some frequency that one pool may have a slot assigned to them that coincides with another pool's schedule of slots. However, the results of the lottery event, to assign the number of blocks any pool may accrue, and the schedule thereof, is done in such a way that a pool is ignorant of any other pool's slot schedule. Pools schedules overlap on the fringes. It is those overlapped schedules that result in two pools getting themselves involved in a "slot battle".
The way slot battles resolve
Prior to the launch of the Shelley Mainnet, during the Incentivised TestNet, the resolution of slot battles was determined either by how fast the pool's node propagated its block onto the network or by which pool had the lowest VRF result. However, the speed by which a pool propagated its block to other nodes on the network had the undesired effect of having the network conglomerated around high-speed network centres in the world (during the ITN one of those centres being Germany). So, in the end, the protocol chose to exercise priority (but not exclusivity - see below) to the pool that had the lowest VRF hash result to process and validate a block.
Subsequent to the launch of the MainNet a pool involved in slot battles would have a measure of their VRF hash made and the lower one would usually win. Pools that have a higher amount of ADA pledged and staked would often have a higher VRF hash whereas pools that had a lower amount of ADA staked or pledged would reveal a lower VFR hash.
Lower VRF hash of a pool wins the battle most often
To understand why a pool with a smaller staked and pledged amount of ADA wins a slot battle more often than not over a pool that has a higher stake or pledge of ADA we can run an analogy. Imagine a dice with 100 sides. Each side represents the possibility of minting a block. The two pools in a slot battle run the dice to see who gets the privilege of minting the block. However, the bigger pool, which has been granted, for example, the privilege of minting 20 blocks has then a roll of the dice where it always lands on a number between 1 and 20. The competing smaller pool has, for example, been granted 3 blocks to mint during the epoch. This pool then gets the dice where it always falls only between 1 and 3. Since the likelihood that the bigger pool will most likely fall on a number bigger than 3 then the smaller pool is a favourite to win the slot battle.
Final word
This answer was written up in response to allay the fears that delegators of a pool who suffered a loss of a slot battle may feel their pool is not operating at its most optimal. It may seem counterintuitive that a superbly performing or large pool can lose a slot battle to a lesser pronounced or smaller pool out there. But the protocol allows for this to happen and it is not necessarily related to the actual performance of the physical pool node or operator running that node!
If the reader has made it to this portion of the answer then they will realize that the result of a slot battle is less about how fast a pool propagates its block on the network, server network latencies, and other physical metrics of a pool. The success of battle has more to do with cryptographic functions and the amount of ADA a pool operates on the network (that is, the pool with less stake being the favourite to win a slot battle).
Refernces:
Beaver Stake Pool: Slot Battles, Height Battles, and Orphaned Blocks
GitHub IOHK Jormungandr Issues: Randomize the outcome of slot battles
Cardano FAQ: What are slot battles?