Can you explain that extra or anything beyond that run ahead is only shaving off frames with savestates ( thats how the lets say inventor explains)
No definitely not 'only'. First there's the emulated hardware+game, if emulation is accurate the driver or core emulation produce more or less the same delay as the actual thing IRL.
Then in an emulator there's the matter of outputing video and polling inputs, potentially other side things like in MAME, but in general this side of the whole emulation package, and the options related to them (like flavours of vsync) produce an additional number of frames.
So they add up, core/game emulation + video,polling,etc, that's why people talk about 'lag chain' (not even counting the PC/OS, controller, and display's own there).
Run-ahead allows you to chew out the video/input/etc part, which is good, but it can go further by chewing out frames from the game's too, those that shouldn't be touched if anyone's concerned about aspects like emulation accuracy and fairness in competitive play. there's also the issue of that 'missing frames' feeling in cases.
A lot of the appeal of run-ahead unfortunately has been that: playing with even less input lag than the originals IRL.
Though again; it depends heavily on what you're playing and settings (as well as PC juice), you could sample 20 RA users and see they all have different understanding of what's going on and all of them different settings according to that, because there's so many variables in RA, it's literally a smörgåsbord of APIs and features borrowed to a ton of other emus and programs and it's possible to abuse proper emulation thanks to that, there is no safeguard.
The confusion and enthusiasm have also created an ideological polarization in the emu scene, with RA users who deny the issues, and for instance mamedev exaggerating them.
Personally I stick to Groovy and the wisemen here because I like the rational and scientific approach without the BS, it's tested, working, efficient without a doubt period.