I don’t have a deep technical grasp of how things work or the ‘why’ behind them

I think it's not needed in general. You might need to go a bit deeper as your project is a bit of an edge case (4GB RAM for desktop) but I don't think you'll need to learn programming

since I’m currently testing Void glibc, it doesn’t use systemd

Ah, I'm not familiar with Void itself. In that case you want to observe outputs of dmesg and tail -f /var/log/messages to see what the system complains about when the crashes happen

I’m open to using older software. At least, I think that’s what you’re suggesting, right? 🙂

Not exactly. Maybe I've lost grasp with how things look like on X, I've switched to Wayland even before it was universal. My thought is: Wayland might have been developed and tested more on stronger machines. While X definitely remembers the times when 4GB was absurdly a lot. So it might work better with lower specs. But if other software has already moved on, it's probably better idea to make Wayland work

My English isn’t the best, so please excuse any misunderstandings.

It's all good, don't worry about it. Sometimes I wonder if there are more people speaking English as second language than native speakers. I'm not a native speaker either

is there a tutorial or a website where I can learn how to properly use musl-based distros? Even though they aren’t as widely used, I believe software built on this library can be more performant

I haven't heard of any such place. In general Arch wiki is pretty good, even if you don't use that distro

I'm not convinced with musl being more performant. I'm not saying it isn't, just that I'm not convinced.
musl definitely has gotten recognition because of the size of Alpine docker image. Because in containers' world, smaller image means less data to send on update, less data to store in Registry, etc. But I've heard second-hand that some people using containers in production started to switch from Alpine to IIRC debian-slim (glibc) because of performance, while still having a small image. And image size does not really matter in your case, you are not running containers here. But all of that is anecdotal, not hard facts.
And in your case, musl might actually be a downside. AFAIU musl statically links everything. So that means that every program you run will have inside the same blocks of code, instead of re-using them via shared libraries. So statically linked binaries will be bigger, and when OS runs a program it has to load it whole into RAM.
Also, if using musl on desktop is less frequent in general, it might be harder to find solutions for problems with it

At home I have an old single board computer with 1GB of RAM. I'm not running a desktop on it but it serves a purpose in my network and works without an issue. So I think a desktop on 4GB should be doable, you just need to find which pieces of software to use.

With older CPU I expect you might run into problems with things like video decoding etc. So not that catastrophic level of failures. Unless the problem is that binaries from packages expect some CPU extensions that you don't have.
With small RAM you might be getting into problems with actually running the stuff. And that has to be mitigated if that's what's happening.
Hence, you need to start observing system logs (dmesg and /var/log/messages) what is going on when the crashes happen and start from there