There are many reasons to limit Work in Progress (WIP). This is explained well by Tonianne DeMaria Barry and Jim Benson in their Personal Kanban blog.

To summarise, limited WIP prevents unfinished work piling up, reduces bottlenecks, reduces distractions, improves communication, helps keep work flowing evenly and prevents wastage. To summarise the summary, limited WIP increases effectiveness.

At LP our Kanban recently showed that we were blowing our WIP limit. This immediately manifested itself in a bottleneck; signoff tasks were piling up. The power of seeing this happen in front of us was demonstrated when we were able to swap from taking on new development tasks to helping with the acceptance/signoff. We were able to clear the bottleneck and get back on track to having work flow through the team more evenly. We also stopped blowing our WIP limit.

We were also prompted to reorganise the Kanban to make the WIP limits more explicit. We'd recently added swim lanes for cloud work and general technical work, but since these were new they'd been added at the bottom. This meant that we piled up cards above them, sneaking work in above our WIP limit without it being really obvious. Now, the (WIP limit 1) swim lanes are at the top and the features and bugs (WIP limit 4) are underneath, so if we hit our limit it's painfully obvious.