Assuming your using OpenAL-Soft, how many sounds are you using and playing at once? Its hard to pin down exactly what the limits of OpenAL may be, outside of the systems available memory and CPU power, though numbers from a "safe" 32 up to 256 have been tossed around. It might be useful to profile your system to see what the CPU and memory load is, and there are ways of catching errors both in OpenAL and python without crashing the program, such as using try/except. There's also a [config file] you can configure to change some of OpenALs default parameters, for example the source limit:

## sources:
#  Sets the maximum number of allocatable sources. Lower values may help for
#  systems with apps that try to play more sounds than the CPU can handle.
#sources = 256

As for alternatives, for the most part OpenAL-Soft is a fairly dependable and feature rich library, I'm not sure if libaudioverse is maintained anymore, otherwise it would be a strong competitor  There's also SDL, PortAudio, pybass or bass4py, rtaudio, and possibly others.

This is where I'd use one or both of something like tiling, or something like a sound_pool. The former would keep a smaller number of border sounds—the maximum that the player can hear at any given time,—and when one goes out of earshot, move it to where the one that comes into earshot should be.
Or you could try something that's not too realistic, and position sounds that need to cover a wide area as the player moves. Ex, if the sound is a plane at x = -100, you'd position that border sound at (-100, listener.y, listener.z).
The sound_pool would basically be writing your own datastructure that manages what sounds should and shouldn't play when. Could also include giving them bounding boxes this way.

For this case, specifically, I'd lean toward tiling.

Another way of putting it would be sector or proximity based sound management. If your using a 10 by 10 2D grid, you'd in essence have 100 "tiles" or sectors, so when a sound moves out of your specified range of the listener, you deallocate that sound, and when one moves into range you allocate a sound. This can be effective for recycling OpenAL sources, and is somewhat similar to the kinds of optimization rendering engines use with Render Distances and such.

Going back to the original issue of getting an out of memory error:
You were probably creating a fresh buffer for every one of your 300 sources and reloading the same sound data into it.
Instead you should be using a single buffer for the fence post sound data, then associating it with all your 300 sources.
In that way you only need to load the sound data into memory once, not 300 times.
Consider a 10 second fence post mono sound with 16 bit depth at 48000Hz.
That would be 10 seconds * 2 bytes * 48000 = 960000 bytes, or lets just round it to 1 megabyte.
So you could either use 1MB for all 300 sources, or more likely you used 300MB to cover those 300 sources.
Imagine that your fence post sound was 30 seconds long, then you would quickly approach a gigabyte of memory usage.
C# programs will crash with an out of memory exception around 1GB, regardless of you having 32GB of ram on your system, unless you specify different configuration options.
Similar default constraints probably exist with other programming languages, such as Rust.

Though as you and others have said, there are much better solutions than creating 300 fence post sources, such as your ray casting solution where you move 4 sources around the listener.
I used something similar to handle river, stream, and pit sounds in A Hero's Call.

In addition to reusing the same buffer on multiple sources, you can deallocate the buffers and sources yourself for sounds that are very distant, as others have already suggested with the tiling/sector/proximity based/distance culling solutions.
Or another great solution is to switch from loading the entire sound file into a buffer and instead use streaming buffers so that only a portion of the sound is ever loaded at once.
For my next project, I am currently using OpenALSoft, with 5 streaming buffers per sound, each of which holds up to 20ms of stereo data, which is 3840 bytes per buffer, or 19200 for all 5 buffers, basically just under 20KB.
This keeps sounds playing well and avoids buffer underruns.
It also has the benefit that each sound only consumes about 20KB of memory, including long sounds, such as music files that can be several minutes long.
And long sounds get loaded very quickly because from the time your code decides to start playing the sound, it only has to wait for the first 20KB to be uncompressed into memory, while loading the entire music file might take multiple seconds and be very noticeable to your users.
You can also combine streaming with the distance culling solutions if you have really huge maps.
Worth noting that keeping your streaming buffers filled is usually done with an additional thread that can wake up every 10ms or so and refill them as needed.

The FMOD Studio and FMOD low level APIs can handle streaming for you, which does make your life easier.
OpenAL expects you to handle streaming yourself, which is more work for you, but also gives you a bit more control.
You probably don't need this control right now, so maybe FMOD would provide a better experience.
FMOD will also handle more audio file formats without you needing to manually include libsndfile, libopus, or others.
I also believe FMOD "virtualizes" sounds that are too far away to be heard, which saves some CPU, but that wasn't your issue, running out of memory was your issue.
I don't consider OpenAL to have big limitations, in fact we were using it for A Hero's Call for much of the development, and only switched to FMOD near the end primarily to allow our sound designer to use the FMOD Studio tool.
I prefer OpenALSoft's license over FMOD's, but FMOD's is pretty reasonable for most people.
I'll be using OpenALSoft on my next project, along with libopus, so I consider them to be pretty reasonable libraries, but I've had a lot of experience with OpenALSoft at this point and I actually have a reason to handle the streaming manually.

Hope my ramblings are a bit helpful.