The main disadvantage of software emulation is that really making the timing consistent with the original hardware is computationally expensive because it needs to account for things like bus arbitration and DMA interactions between the CPU and graphics hardware. This means that you can't get away with JIT translation, or even having your CPU emulation iterate over a bunch of instructions at once. For most games this doesn't make a big difference, but it matters in some edge cases, and also for accurate slowdown behavior (most old-school game engines let physics slow down when the CPU falls behind), which is important for speedruns and other high-level play on some games.
While it's not intrinsic to software emulation, modern PC and mobile operating systems tend to be somewhat bad about input lag by default. This can be overcome, but it's work, and vendors seem to invent an exciting new way to fuck it up every few years.
Similarly, a lot of old-school hardware ran at oddball frame rates that modern systems won't do without a bit of coercion (e.g. NTSC SNES runs at around 60.09 Hz in most modes), so you're usually forced to choose between running the system at a slightly inaccurate speed or allowing periodic stuttering. That being said, modern displays don't necessarily support the original refresh rates either, so FPGA-based systems have needed to make the same compromises, just less often than software emulators.
Interestingly, most 60hz monitors I've tested can tolerate the SNES/NES weird refresh rate without problems. In Windows you can create such a video mode with ToastyX's CRU, and with custom modelines on Linux. All you have to do is take your monitor's native modeline and multiply the pixel clock value by the ratio of 60.0988/your_normal_refresh rate. Within a thousandth of a frame or so is usually close enough, but if you mess with the blanking intervals a bit you can get exactly the same rate.
Monitors generally don't hit 60Hz exactly anyway. A lot of cheap monitors have really inaccurate default refresh rates, like 59.93Hz instead of 60. Some may use 59.94Hz to match NTSC's rate.
While it's not intrinsic to software emulation, modern PC and mobile operating systems tend to be somewhat bad about input lag by default. This can be overcome, but it's work, and vendors seem to invent an exciting new way to fuck it up every few years.
Similarly, a lot of old-school hardware ran at oddball frame rates that modern systems won't do without a bit of coercion (e.g. NTSC SNES runs at around 60.09 Hz in most modes), so you're usually forced to choose between running the system at a slightly inaccurate speed or allowing periodic stuttering. That being said, modern displays don't necessarily support the original refresh rates either, so FPGA-based systems have needed to make the same compromises, just less often than software emulators.