It is common advice to reattach a pending transaction.
But why do I have to do so from a technical perspective? In other words: why does the tip selection not pick up my transaction if it's pending for some time and why do I increase the chance for a confirmation by attaching the transaction to a new position in the tangle.
Two reasons:
When your transaction is seen by the network, it could be already deep in the tangle (several milestones old) which makes it unlikely to get picked for confirmation. This is often caused by PoW being done by a low-end device (or non-working GPU acceleration), so when PoW takes 10 minutes already, there have already been 10 milestones before the transaction is even seen by the network.
It could happen that your transaction picks to approve another transaction which is technically valid at the time/node when you build it, but is later deemed invalid (e. g. when itself was reattached multiple times but another incarnation was eventually chosen to get confirmed). In that case, your transaction cannot get confirmed any more, since otherwise the network would also have to confirm the transaction you approved and therefore confirm a double spend.
In case 1, Reattaching will only help (substantially) if the reattach is quicker. In case 2, no speed limits were involved, so you only had bad luck.
In case 1, instead of reattaching, it helps more (in my opinion) to push a new zero-valued transaction that approves your transaction as well as a really recent tip. Rationale: Single 0-value transactions will only need PoW once, while real transactions need it 4 times or more (depending on signature size). Also, it reduces the number of double-spend transactions which can later act as "time-bombs" by causing case 2 for transactions that try to approve this transaction. Unfortunately no current GUI wallet offers this as an option.
In case 2, pushing any transactions that approve your transactions is counter-productive, though.
The transaction might get attached to the part of the tree that will never be validated for example because there were too many tips in the Tangle tree waiting for validation so that it gets “forgotten” by the tip selection algorithm. The tip selection algorithm is biased towards the transactions from the top of the tree - this is controlled by the Depth parameter. The reason is probably performance - traversing the whole tree when looking for tips would be too expensive.
The process of reattaching a transaction is simply doing the proof of work and tip selection process to reattach the transaction to a different part of the Tangle and thereby creating a new transaction.
If your transaction didn't get confirmed for a long time, it is very unlikely that it will get confirmed in the future because the tip selection algorithm prefers newer transactions.
For this reason you reattach it: to have a higher probability of being selected by the tip selection algorithm (=have a higher probability of being confirmed by other transactions)
