I've never emulated a NES, only an Apple II. The cycle-accurate reads and writes are only mostly unnecessary, but they can make a difference, as the discussion in that linked issue shows.
Yes, it can matter, though you can get far without it. NESticle was plenty popular back in the day without anything resembling proper cycle accuracy.
Note that my NES emulator doesn't even get the total number of cycles right, and as a result Super Mario Bros. 3 crashes. (It really isn't a good emulator!)
I didn't get to the point of caring about interrupt correctness, but I did port the gate-level 6502 emulation to Go, and run Klauss Dormann's fairly comprehensive test suite on both in parallel, checking that all memory reads and writes matched.
Performing the instruction is a 90% solution. You do a 90% solution for the CPU, a 90% solution for the PPU, a 90% solution for the sound, etc, and implement the dozen or so most common backswitching chips. Then 75% of games are playable and 40% of all games are bug free. Maybe less.
Then you start working on those last 10%s, which includes cycle accurate emulation. As it happens, there's a lot of work with goes into the final 10% of the various NES subsystems. Far, far more work than the first 90%.
As for what percentage of games need cycle accurate 6502 emulation I couldn't tell you.
MMC1 ignores consecutive writes, and one games relies on the initially written false value:
> Bill & Ted's Excellent Adventure resets the MMC1 by doing INC on a ROM location containing $FF; the MMC1 sees the $FF written back and ignores the $00 written on the next cycle.
It's equivalent to Apple II. You can get pretty far with the naive solution of atomically completing the instruction, and incrementing the cycle count appropriately, but there'll be some issues until you switch to a cycle accurate state machine with all the warts (false accesses, etc.)
NES actually gets a bit grosser because the PPU runs (IIRC) five cycles for every three CPU cycles or something like that, and you need to handle that case. I've seen some emulators that just run it off of a 15x clock, and sparsely run cycles on the CPU and PPU (but most of the master cycles don't do any work).
I think the NES PPU:CPU clocks are 3:1 for NTSC and 16:5 for PAL. The exact speeds are integer ratios of the color subcarrier frequency. The master clock runs at 6x the color subcarrier frequency, which gives you 12 different hues in the color palette.
Sometimes, especially when dealing with interactions between chips, even sub-cycle behavior needs to be emulated for correctness. I suspect for basic emulation though, rigorous cycle accuracy is not really necessary for most software...
I'm curious: are the cycle-accurate reads and writes (and false reads and writes -- see https://github.com/zellyn/a2audit/issues/5) not necessary for NES emulation?
I've never emulated a NES, only an Apple II. The cycle-accurate reads and writes are only mostly unnecessary, but they can make a difference, as the discussion in that linked issue shows.