What reasons would CPU designers have for choosing these different approaches?
It depends on what the designers intended to mark a valid bus cycle, which is the 'leading' signal for decoding. In a more general way, it's the design view of the bus.
Common ways (*1) are:
The 8080 way - Marking a cycle by a one of several (*2) dedicated signals marking the type of cycle as well as its validity. RD and WR mark a read or write cycle as well as the validity of all other signals.
The 6800 way - A dedicated signal marks the validity of an access cycle, putting all other in context. VMA (Valid Memory Address) is used to indicate a cycle. R/W defines the direction of this cycle.
The 6500 way - Each and every clock cycle is a valid access cycle. No dedicated signal is needed, the clock signal can be used for this purpose. R/W defines the direction.
So while there is a basic difference in the way a bus is viewed between the 8080 and 6800 way, both need two signals to create a valid cycle and direction. The 8080 solution is more simple to decode in peripherals, especially if built up from general TTL, while the 6800 got a more abstract view. Both have the advantage that I/O and memory does not need to be clocked. And both offer support for DMA/bus-sharing, as well. The 8080 maybe more so than the 6800, as it includes a bus request protocol, while the 6800 only supports bus separation by tristating its signals.
The 6500 way is a simplification of the 6800 bus design (*3). By making each and every clock cycle a bus cycle (and having the CPU output a valid direction and address during that), one pin on the CPU could be saved. On the downside, non-6500 peripherals had to incorporate the clock signal into their enable decoding (*4). Then again, the latter isn't as much of an issue as it also hits the other schemes at some point as well, depending on the peripheral used.
Even more cumbersome is the fact that this simplification made DMA/bus-sharing hard, requiring external buffers and logic (*5).
It may be worth noting that there were many more variations that these three - as there were many more microprocessors.
(For everyone's sanity I skip the bus state controlled cycles of an Intel 8008 :))
From a historic point of view ,the 6800 way is the most versatile and similar methods are found many mini computers as well as other microprocessors - like TI's 9900 (here called MEMory ENable).
The Signetics/Valvo/Philips 2650 was somewhat similar, but featured in addition to a valid address line (ADRess ENable) a WRitePulse line, only triggered during write cycles - which were also announced by R/W being high. So a kind of mixture of 6800 and 8080 - satisfying both protocols for most parts. The CPU also featured a quite fine-tuned framework for bus sharing.
Nationals SC/MP takes this a step further by using a multi-master bus protocol by default. Only when the bus is granted a bus cycle is indicated by NENOUT, followed by an address strobe (NADS) and then followed by a write or read strobe (NWDS/NRDS) (*6). Using this, and taking the many internal cycles without bus access into account, two SC/MP could be coupled in a system with almost no performance penalty.
Speaking of weird, the RCA/Intersil CDP1802 does feature a bus design somewhat like the 8080, with separate read and write lines (MRD/MWR); these do not validate other signals, but only indicate direction ... and to some extend 'alert' components ahead of time - 5 cycles for read and two for write. The transfer itself is initiated by the TPB signal validating the lower address half - which at that point is already valid for more than 3 cycles.
In fact, it isn't really weird, but far far away from the simplified and abstract bus designs we are used to see later.
Even Zilog's Z80 isn't as simple as many assume. Where the 8080 signalled the type of a bus cycle during the first clock of each machine cycle (marked by SYNC), the Z80 offers separate signals to main memory (MREQ) or I/O access (IORQ), resulting in 4 pins dedicated to framing and signalling where 3 would have done been sufficient. Looks like a less than optimal middle way to keep 8080 compatibility.
In this context Intel's 8085 changes/simplifies the 8080 bus, as now IO/M is a dedicated signal to be decoded during RD or WR. No more 8224/8228 combination needed. It's eventually the most simple form of the 'two signal' variation. Except now the address bus is multiplexed and a latch for the half transferred on the data bus (and signalled by ALE) is to be added. 40 is a fricking low number of pins anyway.
The 8086 then continued along that way, combining both worlds: Separate RD/WR/IOM signals and multiplexed address bus with the multiplexed status signals of the 8080 ... plus even more creative encoding in maximum mode.
Bottom line, there were way more than just two ways to access memory (and even more if I/O is separate).
*1 - Processor names are used for simplicity of explanation and will not mark any invention or origin claim.
*2 - For the raw CPU it's only two dedicated signals RD and WR, as the split into memory and IO is only communicated by THREE status signals multiplexed on the data bus during SYNC. This word needs to be latched before decoding. A function the 8228 Bus-Driver/System controller provided - which in a clean system would as well need by the 8224 clock generator combining its PHI1 and the CPU's SYNC into a usable strobe signal (STSTB). Quite a mess, understandable the Zilog changed that part - and so did the 8085.
*3 - The 6500 development history becomes quite clear when looking at a minimum 6800 system, here Motorola suggests to combine PHI2 and VMA to create a generic Enable signal. With the 6500 design as a simplified, cost reduced 6800 focused on embedded application, having this combination already by default and saving a signal to be outputted was a clear plus - not at least by freeing up pins to make the integrated clock generator work and save even more.
*4 - On the plus side, complex 6500 I/O units will have a clock signal already present, which comes handy for any kind of timer/counter application.
*5 - Something various later spinoffs eased - all the way to the WDC65C02 reintroducing a 6800 compatible interface.
*6 - Unlike in the question implies, it's only as simple as with the 8080, when there is no other bus user and the CPU always gets its way ... and even on its own, there's the multiplexed bus and NWDS/NRDS being non-overlapping with the NADS address strobe.