There's nothing wrong with wanting to stick to original hardware, if you already have it or can afford to buy it.
Setting up a Pi or other single-board system as a dedicated retro game emulator is also an absolutely valid choice IMO. It's a fun, generally affordable little project that you can tinker with forever, e.g. changing cases and controllers, UI tweaks, ROM file organization, per-game settings optimization. But I don't think that it's ever been the "best" emulation option for anyone who didn't already have their heart set on "doing something fun and interesting with a Pi".
The smartphone you already have, dedicated retro gaming handhelds, Android TV boxes or sticks, and cheap/secondhand/already-owned PCs (desktop, notebook, or kiosk) all arguably match or exceed the performance and value-for-money of any Pi-based system.
Yet in any thread where someone new to emulation is asking for advice, there's always a flock of folks who suggest getting a Pi like it's the only game in town. It honestly baffles me a little. Especially because almost all of them are just running a pretty frontend over Retroarch, and Retroarch is available for virtually every modern consumer computing platform (and so are a lot of pretty frontends, if that's a selling point).
For context, I've got a dozen or so retro systems, but I prefer to emulate as much as possible.
I have been emulating many different systems (including SNES) on lots of platforms, and have almost never been bothered by lag in the emulation itself.
But one day someone was harping on about lag in an SNES game, so I loaded it up (Android RA SNES9x core) just to double-check before arguing with them... and indeed found the lag quite noticeable. But I also found two ways to reduce the lag significantly.
The first thing is to try different cores. There are multiple versions of SNES9x available on most versions of Retroarch, and there's a reason for it. The different cores can give surprisingly different results for a single game.
The second thing (which had the greater impact for me) is to enable Retroarch's look-ahead emulation for one or two frames. Just as it sounds, this will cause the core to emulate the next n frames with every possible combination of inputs. It increases the processing requirements exponentially, but for something like the SNES, many platforms can handle it. I know it seems counterintuitive (if it can emulate hundreds or thousands of possible frames in realtime, why can't it do just one?) but it worked for me. It must be some kind of throughput vs. latency thing.