The cost of a branch misprediction depends on the depth and width of the pipeline and not the amount of code guarded by a condition. A processor keeps fetching and decoding down the wrong path until the branch is resolved and the correct target determined. In a two-wide processor with five stage before branch resolution (a "moderate performance design", say two instruction fetch stages, a decode stage, a register read stage, and an execute stage with a branch resolving at the end of the execution stage), a mispredicted branch could lose up to nine instruction execution opportunities:
br+w1 IF IF ID RR EX
w2+w3 IF IF ID RR EX
w4+w5 IF IF ID RR EX
w6+w7 IF IF ID RR EX
w8+w9 IF IF ID RR EX
c1+c2 IF IF ID RR EX
In most real code, two consecutive instructions would not always be able to execute in parallel, so the actual lost performance would be lower. (If the branch was the second instruction of a pair, only 8 instruction execution opportunities would be lost.)
In a fully predicated ISA, the predicated form could also have one less instruction (a branch instruction might include a comparison that would have to be provided as a separate instruction to provide a predicate but often normal instruction results provide a predicate).
Another consideration is that predication avoids fetch redirection. Some implementations have had a one cycle taken branch fetch penalty; for a two-wide processor, this would allow two predicated instructions to execute "for free".
(Out-of-order execution complicates the tradeoffs in providing and using predication. Predication turns an instruction with two dynamic sources into one with three dynamic sources, so the scheduler has to monitor the availability of an additional source (the predicate). In addition, predication converts a control hazard (which can often be bypassed using prediction) into a data hazard (if the predicate is not available, the instruction will not execute and its dependencies cannot execute). In theory, predicates can be predicted just as branch direction is predicted with the prediction only used if the data hazard is expected to introduce excessive slow-down, but this requires both a confidence estimate for the prediction and an estimate of the costs for using and not using the prediction when the prediction is right and when it is wrong.)
Furthermore, not all branches are equally predictable. Some branches approach fifty percent predictability. It is even possible to always mispredict (e.g., with two-bit counters initially at weakly wrong for the first encounter and a branch that alternates between taken and not-taken), though this is a rare occurrence.
Predication of nested conditions can also exponentially increase the number of executed instructions. Branch prediction would choose one path for a switch statement; complete predication would follow all the paths.
Another factor is that processing extra instructions can be relatively inexpensive if the processor has otherwise idle resources. E.g., if one path is stalled waiting for the result of a long latency instruction (or cannot fully utilize available execution width), (predicated) instructions from the other path may be able to execute "for free" (power and other costs would still apply).
Predication also makes more sense with vector/SIMD operations where per-element predication can facilitate the use vector operations that would otherwise need to be executed in a scalar fashion. (Even without predication, one can use bitwise SIMD operations to select operands, choosing between the true operand and the identity value for the operation.)