Wait I just did a full C benchmark, the results are

80.3 ms ± 29.2 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)
239 ms ± 133 µs per loop (mean ± std. dev. of 7 runs, 1 loop each)
80.4 ms ± 208 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)

183 ms ± 712 µs per loop (mean ± std. dev. of 7 runs, 1 loop each)
420 ms ± 1.15 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
184 ms ± 782 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)

Looks like the performance of log and log10 is consistent between numpy and my implementation, but log2 is way slower than them. Maybe there isn't a good enough SIMD for that?

But anyway the performance of np.log2 is indeed slower than expected.

Related SO: Why are log2 and log1p so much faster than log and log10?

The difference is probably that at least log has explicit AVX vectorization, and your loops the compiler probably manages to do that. I find it plausible that @r-devulap already has improvements in the pipeline. Although, we may not do it in some cases if the improvements are small.

float32 log in NumPy 1.17x uses AVX2/AVX512 intrinsic (see PR #13134). Although, the algorithm easily extends to log2 and log10 and its my to-do list.

So it might take a long time before fast log2 will be implemented in numpy?

Anyway, a quick fix would be

a = np.ones(2**27, 'f')
%timeit np.log2(a)
%timeit (lambda x:np.divide(x, np.log(2), x))(np.log(a))

480 ms ± 541 µs per loop (mean ± std. dev. of 7 runs, 1 loop each)
160 ms ± 34 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)

A quick precision test

a  = np.random.rand(2**27).astype('f') * 1e9
np.linalg.norm(np.log2(a) - np.log(a)/np.log(2)) / len(a)

9.88357312659005e-11

@ZisIsNotZis that is not a viable "quick fix" within numpy (and probably a bad idea also, since not all arrays can be accelerated with AVX). Having it on Raghuveer's todo list is probably the best way to have it fairly quickly, which likely means it is in 1.18.
If the quick C tests made faster code, I guess the compiler was capable of optimizing things a bit. So it might be that just just creating special contiguous paths on a specific (not passed in) function is enough.

see #19478