A simpler alternative would be to use the general method that numpy uses in its sinc:

    alpha[alpha == 0] = 1e-20
    sinc_alpha = sin(alpha)/alpha

But it looks like there is more to it than just getting sinc(0) = 1. See below.

The singular point is just the center point, (x, y) = (lon, lat) = (0, 0). So it looks like the modification suggested above would work fine, eliminating all of the subsequent indexing, simplifying and speeding up the code.

Working through the same thing below, alpha = 0 from arccos comes from input of 1 from cos_latitude * np.cos(half_long). Using the same limits, that can only happen if longitude = latitude = 0. To ensure that the result is 0 with sinc(0) = 1, the numerator of both calculations needs to be 0. Fortunately, we have sin(longitude|latitude) in both which nets 0 there too.

I think this will work out just as well.

Can sinc_alpha be zero? If so, the original masked array version was handling that case and the present version does not appear to be doing so.

sinc_alpha comes from sin(alpha), which can only be zero if alpha == nπ. alpha comes from arccos, whose output is [0, π] and since 0 is masked, we only need to worry about π which is from input of -1, from cos_latitude * np.cos(half_long). The limits are -π/2 ≤ latitude ≤ π/2 and -π ≤ longitude ≤ π (and cannot be changed), that's also -π/2 ≤ half_long ≤ π/2, so both cos terms (and the entire input) are [0, 1]. Thus it's impossible for sinc_alpha to be zero.

Thank you. (Sorry, I was too lazy to figure that out for myself.)

np.maximum(alpha, 1e-20, out=alpha) should work better if you somehow have tiny alphas (between 0 and 1e-20) and also saves an extra allocation, I think.
(or alpha = np.maximum(alpha, 1e-20) if you don't want to obfuscate it :-))

It's fast either way, but np.maximum takes more than twice as long, at least in my test with 10,000 pts. I think the 1e-20 is a completely arbitrary small number, and its only purpose is to prevent division by exactly zero. A tiny number still works:

In [21]: np.sin(1e-300) / 1e-300
1.0

I like column_stack, which I think has a very descriptive name... (but it's just personal preference)

pre-allocating and then assigning to slices is faster, and still very readable.

I think it's essentially the same speed (not that it really matters):

In [15]: %%timeit x = np.random.rand(10000); y = np.random.rand(10000)
    ...: z = np.column_stack([x, y])
    ...: 
37.8 µs ± 216 ns per loop (mean ± std. dev. of 7 runs, 10000 loops each)

In [16]: %%timeit x = np.random.rand(10000); y = np.random.rand(10000)
    ...: z = np.empty((10000, 2))
    ...: z[:, 0] = x; z[:, 1] = y
    ...: 
36.7 µs ± 1.39 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each)