Preface 1: The way it is asked, it's way too broad for an answer to make any sense. Especially making some assumptions at the same time as widening it across all different CPU memory interface technologies there were.
Preface 2: Design decisions for wait state design and application is a topic for a whole course on system design. It's next to impossible to give a satisfying answer to this in general within a single unspecific RC.SE question.
PC compatibles in the 1980s were often advertised as having zero, one, two, or sometimes more "wait states". Zero wait states was the best.
It looks like, at first sight, but looking closely, systems without are more often than not the slower ones.
Basically, the RAM was too slow so extra bus cycles were added to make up for this latency. That reduced the overall processing speed.
No, not really. It's much more complex than that, so it may be a helpful to restrict this to the core of wait state usage on IBM and compatible machines of the 80286 area where the question was most prominent and seems to have originated.
To start with, a wait state isn't an issue of memory but of the CPU. It's the CPU design requiring memory access to be synchronized with the clock speed used. An 8086 class CPU always takes four clock cycles per memory access, while it is two with a 80286. For the following we go with the 80286, as it's a quite different timing than on the 8088.
For an AT running at 6 MHz this two cycle structure would make a basic access time of 333ns per bus cycle, but the structure is a bit more complex. The first cycle is a setup cycle where all control signals are presented (called TS), while the second is called command cycle (TC) and contains the operation itself and handshaking. This cycle will be extended as long as there is no acknowledge from the memory system (called Ready). Intel added some quite nifty structure to enable the full use of these two cycles for memory operation, like address pipelining, which offers a stable address before the first cycle. Using this requires non-trivial circuitry.
IBM chose a more simple approach. The decoding waits for the raising edge of ALE, when all signals (status like direction and memory/IO) are valid, simplifying decoding a lot. ALE becomes valid a few nanoseconds after the first half of TS, reducing the time available for decoding and memory access to somewhat less than 250 ns. The AT was designed to run with 200 ns RAM access time, so already tight, especially when considering that RDY needs to be assigned by the memory system before the second half of TC, effectively reducing the timing to less than 133ns. Way too short.
For the AT (5170 Type 139), IBM decided to be better safe than sorry, adding a wait state. In addition, it also made sure that access time for I/O cards would stay within the limits set by the PC. Equally importantly, with a wait state, they could be sure that there is no chance a less than perfect charge of RAMs would screw the quality. Considering that the AT was about three times faster than the PC, there was no need to take any risk.
With the later PC-XT 286 (5162), with basically the same design (and the same 200 ns memory), IBM went with zero wait states. Maybe they became more confident.
Then again, it's also possible that the whole system was already designed to run at 8 MHz from the start and has been only slowed down to 6 MHz for company policy reasons. In that case, the wait state does make a lot more sense, as an 8 MHz design (as IBM did) can only run with 200 ns RAM by implying a wait state. Similarly to keep the slots compatible. The difference between 6 MHz AT (type 139) and 8 MHz (type 239) is basically just the clock chip.
Bottom line: It all comes down to design decisions. With a more sophisticated decoder circuitry, 200 ns RAM can work well with a 8 MHz 80286 without wait states - as many other 80286 machines of the same time showed.
Now, then there was the race to more MHz, cranking 80286 machines up from original 6/8 MHz past 12 or 16 MHz. At that time there was no memory fast enough to support this speed. Even adding a more sophisticated decoding, as for example NEAT boards added, couldn't help at the higher end.
It might be important to remember that memory access of the 8086 family is different from next to all previous or contemporary CPUs, as only data access was synchronous. Code was read ahead of time by asynchronous BIU operation, resulting in fewer unused cycles compared to a 68k. This is the reason why Intel CPUs performed quite well in comparison.
But I don't recall this being an issue on comparatively-priced machines with 16 or 32-bit Motorola processors, and running at similar clock speeds.
Comparatively-priced is a more than vague term, considering that fully-fitted PC could well outprice high end workstations. And neither is clock speed an issue, as clock speed is only marginally related to memory speed. As mentioned before, it's all about memory access (and cycle) time. Other CPUs were hit by the same problem when clock speed increased. A 68k used at least two cycles per access, which means that 200 ns is fine for a 8 MHz 68000 (assuming a simple decoding circuit). Anything faster than that will also require wait states.
What was the cause of the wait states, precisely, and how come other low-cost home computers were able to avoid this performance problem?
Because they where fricking slow :)) Considering RAM speed of the time, it's obvious why even upper end machines, like a SUN 1 or 2 ran at 'only' 6 and 10 MHz. It wasn't until the 68020-based SUN 3 reached 15 MHz - enabled by the 68020's cache, as memory access was done with three wait states.
Even many, many years (1992) later, Commodore's Amiga 4000 (A3640 CPU card) used 3 wait states by default to adapt the 25 MHz CPU to slower memory.