On the 8080 and 8085 microprocessors, a LDA instruction took 13 timing(or T) states to execute. This could be solved by using a ring counter that could generate said 13 T states,as well as having variable instruction length in the control unit that is generally guaranteed in microprocessors. So if this method is so efficient and not very taxing on hardware, why did they switch to having multiple machine cycles per instruction? That sounds like it would require massive amounts of hardware to back it up, much more than having a larger ring counter. So why did they make the switch, and is the hardware to back up multiple machine cycles simpler than I thought?
In the 6502, there are principally three reasons for taking more than one clock cycle per instruction. The 6502 (in common with 65xx and 68xx family CPUs) can transfer one byte on the memory bus per cycle, which is generally better than "80 family" CPUs in which the bus protocol is more complex.
The first reason is that more than one byte may need to be transferred on the bus. For LDA absolute, four bytes are needed - three instruction bytes (opcode, address low, address high) and the actual data byte.
The second reason is that there is limited execution hardware and register space inside the 6502, which was designed to a price point of $25 in 1975, several times lower than its nearest competitors. So for a few instructions and addressing modes, an extra cycle or two is taken to wait for some data to get out of the way before putting another value in its place.
The third reason is that in a couple of cases, complex microcode was reused with some parts suppressed, which resulted in seemingly unnecessary cycles taken by comparatively rare instructions. This includes the "instruction" executed in response to a Reset signal, which reuses the microcode for taking interrupts and executing the BRK opcode, as does JSR. RTS and RTI also share microcode, the latter performing an extra operation in a "dead cycle" of RTS.
You will find similar reasons in the design of other early CPUs. Some of these will have an additional reason - that executing an instruction inherently takes several sequential steps with the hardware provided. This is normally true of multiply and divide operations, which use a shift-add type implementation to avoid the need to implement a very large and expensive piece of logic.
Many early microprocessors take multiple cycles per memory operation not because they are microcoded, but because they have limited ALU resources, and because they can't start computing something until they've received the values to be computed. The Z80 has a 16-bit increment/decrement unit and a 4-bit general-purpose ALU. The 6502 has a program-counter increment and an 8-bit ALU. The CDP 1802 has an increment-decrement unit that operates on 16-bit registers (it might operate two bits at a time; I'm not sure) and a 1-bit general-purpose ALU.
The 6502, for example, has one 8-bit ALU, and requires that on every memory operation, each half of the address bus has either be determined based upon information that was available before the start of the previous cycle, or else be directly copied from the value received on the data bus during the last cycle. When the CPU is fetching an opcode, it has no way of knowing whether it might need anything other than the byte immediately following it, so it may as well start fetching the next byte. When the 6502 executes a branch, it won't have the information needed to compute the branch target until the end of the second cycle. Since the branch target won't be available at the start of the third cycle, the CPU won't be able to fetch code from there. If the 6502 had a 16-bit ALU, it could consistently fetch the instruction following a taken branch with only one wasted cycle, but the 8-bit ALU makes it necessary to compute the LSB during the third cycle, and then compute either PC MSB+1 or PC MSB-1 during the cycle after that while it fetches a byte using the old MSB and computed LSB. If it turned out that the branch didn't cross a page, the fetched byte can become the new opcode. Otherwise the fetched byte will be discarded and another byte fetched using the re-computed MSB.