The main reason is you trying to find it in the agent part (3rd group enclosed in quotes), so [^"]*"[^"]*" \d+ \S+ "[^"]*" would bypass the "URI-part", response code (\d), size, "referrer" and then search for %(wpblock)s inside the "agent"...

Try something like this:

- failregex = ^(?:\[[^\]]*\] )?<ADDR> [^"]*"[^"]*" \d+ \S+ "[^"]*" "[^"]*(?:%(others)s|%(wpblock)s)[^"]*"$
+ failregex = ^(?:\[[^\]]*\] )?<ADDR> [^"]*"[^"]*(?:%(others)s|%(wpblock)s)[^"]*" (?!200)

([^"]* - bypass anything but not "-char, then match "-char (open quote for method+URI-part), then again anything but not ", then the string matching others or wpblock ...)

However it still looks a bit ugly too me (the part (?:%(others)s|%(wpblock)s) is not bound, so can match as part of some word, or even get-argument. For example when index.php is totally valid URI, the request like this /index.php?user=wp-administrator will be detected as a failure. So either use \b (word boundary), or better restrict it in the group wpblock more precise, for instance /wp-admin/.
Also it is not so good to ban everything (even 200), so I added negative lookahead (?!200) to bypass them. Also 301th response (aka persistent redirect) for non-existing URI is a bit strange (shall it not be 404?)...
I don't have wordpress and never used it, so no idea what can be legitimate and what not.

Also note that monitoring of accesslog directly is not recommended, see wiki :: Best practice... For instance, one could deny unwanted responses on side of web-server. and write forbidden requests to different log (much smaller than your accesslog), and then ban everything matched in this log.