I started learning BH recently (very late, I know, haha), so I was wondering how one could optimize BH for speed rather than for move count.
I started working on the first 30 cases, and so far it seems pretty fast.
Which cases would need to optimized and how would they be optimized?
I would say to use the U PLL alg in a lot of the edge cases. The reason we optimize for move count is to be able to use the entire method on bigger cubes. Technically the page that talks about 3x3x3 corners and 3x3x3 edges that Daniel and I made up should be titled "corners on the n x n x n cube" and "central edges on any odd n x n x n cube"
As for optimizing for speed, basically if an alg sucks then just use a PLL that is faster. I also recommend to use all of the "Slice-Plane" type edge commutators, as they are crazy fast on 3x3x3 compared to the supercube safe versions.
Sorry that this post will not really be all that much help. Daniel and my focus is really to be able to have a fast and efficient method for big cubes. It just so happens that using BH is possible on the 3x3x3, but we did not intend the method to maximize the speed for 3x3x3.
I would say that the BH corner algs would be hard to beat in terms of speed, unless you are just really crazy fast at your A perms. I think Haiyan might disagree with me on this point

but I think that BH corners would already be fairly well optimized for speed already. BH edges would have a long way to go to being optimized for speed, because there are a lot more capabilities on 3x3x3 since the U perm is just so incredibly fast. Seriously though, the "Slice-Plane" commutator type which works on 3x3x3 just can't be beaten in terms of speed:
M' U2 M U2. I'm sure a huge number of algs could be speed optimized using Slice-Plane algs compared to even a U perm.
Hope this at least helps a tiny bit,
Chris