Reason 1: It was the norm at the time
In the early to mid-80's it was the norm that a given platform, whether console or PC, that it was relatively static. The CPU was running the same speed on all devices and the video system and memory was often the same across machines of the same platform, barring some regional changes (eg. PAL vs NTSC).
For games, what would also usually occur, was that a game would often get completely ported to a new system or platform - sometimes resulting in a vastly different game between eg. a C64 and a NES.
While different platforms could have the same CPU (eg. a Z80), the underlying architecture of the rest of the system could also be vastly different, especially when looking at the video output system. In many cases, it resulted in simply being much easier to rewrite large parts of a game to adapt it to the new platform - while you were there, you adjusted the game loop timings accordingly.
Reason 2: Hardware
Most computers and consoles at the time did not contain other reliable timers than the CPU itself, meaning that, often, that the programmer simply did not have any other option.
At the same time, home computers and consoles were often rather simple, single-tasking setups, and resources were often very constrained.
It wasn't really until the PC platform started to include the 286 processor that a given hardware platform could include a multitude of different CPUs.
Yes, you could do rudimentary hardware detection to adjust the game speed and timings, but implementing such a system takes time and resources, and it wouldn't always be reliable. Often, the PC would have the (now classic) Turbo button as well.
The 286 did pose some additional problems as well (as well as the later x86s), as some instructions in the CPU itself were optimized, which could throw off the timing of game code all on its own. And old instruction that took 8 cycles of CPU time, would now take 2 or 4, for example.
Reason 3: Software
With the constrained hardware resources at the programmer's disposal, the most major problem was often not having enough resources to make use of high-level programming languages. At the same time, there was no room to run and make use of all the fancy APIs and libraries that games often make use of today. Programmers would have to interface and make use of all the hardware manually.
As a requirement, most games above a certain point (ie. all the fancy games with good graphics etc.) also need to focus on speed in order to handle all the things a game would need. Everything, such as the fancy graphics, sounds and input would all need to be handled in a timely fashion.
That all means that the programmer was often relegated to using pure Assembly or directly using machine code for their games. BASIC and other higher-level languages would all plain be too slow to produce satisfying results on these old platforms.
Reason 4: It was simply much easier
Still today, when writing a game engine from scratch without fancy libraries and APIs, it's much easier to adapt directly to the hardware.
However, said libraries and APIs make it much easier to write games for a multitude of different hardware configurations. In a modern PC, you also have such things as a fairly exact RTC module that can help time operations down to fractions of a millisecond. Along with these features, the OS also holds your hand in different ways by taking care of hardware calls and handling concurrency/parallelization.
Summing it up:
All the modern, fancy stuff in the previous paragraph did not exist back then. Plain and simple. Combine that with the lack of variation on most platforms until around the mid-80's, you have the two answers to why many games were CPU-bound. It was often too difficult to implement hardware detection and code that could adapt to differing hardware. Concerning the platform landscape at the time, it was also often unnecessary to implement such a feature.
As for the PC market - even when the 286 was around, many developers would then simply program the game to fit the 286. Even then, the relatively minor differences in clock speed (most often between 10-16 MHz for most consumers) on the 286 would not pose significant differences in the speed of the game.
As a result, it wasn't really before the 386 era that time-bound game logic became best practice in the gaming industry. The clock and speed differences on the CPU (for the 386, between 12 and 40 MHz) now posed a larger issue for the speed of a CPU-bound game.