Earlier quoted context omitted.
Trivia: 1Blocker convinced apple to raise the limit from 50k to 150k per list for Safari content blockers.
My question is why have limits
But there are probably some DX and UX improvements over unbounded lists. e.g. recompilation takes time, so you set up developers for better UX when their dynamic lists are shorter and separate from their static lists, and they can compile multiple lists at once. (A 50k rule list took seconds on my old Macbook Air). Also encourages breaking lists into logical sublists which is better UX (e.g. regional lists)
Also might discourage append-only accumulation where there’s no real incentive to prune the list (i.e. see EasyList). Some limit can help here.
Kind of like deciding on a queue size vs unbounded: makes sense to set a limit, see who hits it, and cross that bridge as needed. In Apples case, they 3x’d the limit after a real world product made a real world case.
Just some thoughts having built my own Safari content blocker.