By apparent reasons.
For an unconditional breakpoint, you can seed a hardware instruction(s) to call a debugger. In particular, on x86, x86-64 or IE-64 instruction set architectures, there is a hardware support of debugging, and the interrupt instruction can be used to set a breakpoint. Please see:
Many other processors also have hardware support for breakpoints:
The main point here is: when a breakpoint is unconditional, you don't waste any CPU time for the breakpoint until the code flow comes to the breakpoint instruction; the debugger should be invoked at the first occurrence of the breakpoint in the code flow.
It cannot work this way if the breakpoint is conditional. You need to inject some code, which checks up the condition first, and, depending on the result of the check, either continues execution or calls the debugger. You might perceive this as a low-performance process if many checks without passing the control to the debugger take place before it happens.
But should you consider this as low performance? If depends on what you want to it compare with. It can be considerably slower compared to the runtime without the debugger, but your purpose is to debug, right? So, compare it with the case when you still have millions of passes through the breakpoint, but make it unconditional, so the execution will be paused every time… Still slow? Well, you cannot guarantee the ease of debugging in all cases… :-)