The x86 assembly for fetch_or looks like this (when the value is discarded):
lock
or byte ptr [rsp], 51
That's actually one instruction: lock is an instruction prefix that modifies the next instruction. Specifically, lock makes the instruction be executed atomically. Intel's x86 manual specifies what instructions support the lock prefix. Bitwise not supports the lock prefix
This instruction can be used with a LOCK prefix to allow the instruction to be executed atomically.
So if there's an x86 instruction for it, why isn't there an atomic operation for it? LLVM doesn't have an intrinsic for it. In Rust, the Atomic* functions all forward directly to an LLVM intrinsic, so only the operations that had a corresponding LLVM intrinsic got a function. The memory model for JavaScript atomics "takes significant inspiration from LLVM", so it doesn't seem like a stretch to guess that the Atomics functions were just copied from what LLVM had.
LLVM supports 6 intrinsic operations: add, sub, and, or, xor, and nand. It supports those ones because GCC has intrinsic operations with the same names (except for the type). Atomic and, sub, and, or, and xor operations were added to GCC (nand was added later) as a part of adding support for std::atomic in C++11.
C++11 has 5 bitwise atomic operations in std::atomic: add, sub, and, or, xor. (but not nand, which gets an intrinsic in GCC but no actual support in std::atomic). Why? Because that is what was suggested in the 2007 paper originally proposing atomics in C++, which defines the operations "fetch-and-{add,sub,and,or,xor}". They don't provide a reason for only having those 5 operations, but my guess is that they wanted to minimise the amount of implementation work for compiler implementors, since you can get a NOT operation by XORing against all ones. Or maybe they just didn't think about it.