I've found the solution, and it's exactly as stupid and obvious as I was expecting.
The classroom computers were deployed using Clonezilla from an image that had the VirtualBox VM pre-configured. As a result of this, every VM had the same MAC address, which probably caused a lot of ARP collisions, since all the hosts and VMs were essentially on the same broadcast domain.
The solution was to simply randomize each VM's MAC address. After that, ICMP, SSH, and HTTP worked as expected. Thanks for the suggestions, but it was caused by my own oversight in the end.
(edit) I got around to reading the comments just now, @maxy@piefed.social was totally correct.
I know this isn't "selfhosting" as most people imagine it, but it is about hosting services on own hardware, hence why I'm posting in this community.
I'm supposed to help a teacher set up a networking exercise where pairs of computers are connected directly on a crossover cable and can access services (echo, HTTP, SSH, FTP) on each other. Every computer is identical: Windows 10 host, one VirtualBox VM running Linux Mint with a bridged adapter in promiscuous mode. Each host and VM has its own static link-local IP address.
The problem is, the VMs can't talk to each other, and I don't know why.
From one VM, I can ping itself, its host, and the remote host, but not the remote VM. Each host can ping itself, the local VM, the remote host, but not the remote VM. I've tried connecting both hosts to a layer-2 switch, with the same result.
Can someone point me at the one thing that I'm obviously doing wrong?
(edit) I've also tried to set the default gateway to the host's, remote host's, and remote VM's address, but nothing changed.

Running Linux on metal isn't an option. In the past, the classroom computers used to dual boot Windows and Ubuntu, but the Windows install got so bloated (the software too, not just Windows) that it needs the full SSD.
Rolling release doesn't mean that no testing is done. All updated packages are tested by maintainers before being released into the official repository. A rolling release simply means that there are no individually marked OS versions and you always get the latest packages.
In contrast, take Debian for example. It uses a point release system with major named versions (e.g. Debian 13 "Trixie"), minor point releases (e.g. 13.1), and security and bugfix patches between those. New feature updates are released only between point releases, and breaking changes are only introduced between major versions. This allows the maintainers to practice a greater amount of care in testing that the packages work well together, but also means that new features are always held back to some extent. This does not happen in a rolling release system. All upstream changes are pulled, tested, and released, regardless of whether a breaking change is introduced.
By its nature, a rolling release distribution will require a greater amount of maintenance. If a package update requires manual intervention, it will be published on archlinux.org. For as long as I've been a Linux user, I've only seen one package update that made systems temporarily unbootable, and I was saved from that by being a Manjaro user at the time.
But, to answer the question, I usually update my home and work PCs (both Arch) about once every week or two, or as required by a new software or important security update.