The "not so good" case are tripple A games with a big fat budget, because Java lacks middleware and because the big studios lack Java programmers. Another case is hand crafted SSE/2/3/4 asm code, which may speed up some specific bits enormously (but thats more of a thing for raytracing, media en/decoding etc... for the most part it isn't worth the trouble).
Within the hobby to shareware range (small team/small budget) those things don't matter. Especially if it's 2D stuff. There isn't much to calculate anyways usually. No one cares if the game could run at 500 instead of 450fps if the graphics card limits it to 200 in first place.
My machine is 7 years old by now (500mhz ugh), but even with that pile of ancient crap I make it rarely drop below 60fps (with lwjgl that is). And if it does... then I'm either doing something overly processing intensive, something stupid or both.
game for example runs at 140+ fps (while ~10% of the cpu is used elsewhere). And Tribal Trouble
runs at playable ~30fps.
A 2D RPG would run fine, too. Even with immediate mode rendering and doing a few stupid things here and there. 60+fps would be a piece of cake... even for my machine. (Filling 640x480 with 16x16 tiles [immediate mode] while using ~45% of the cpu elsewhere gives me still ~140fps. There is absolutely nothing to worry about.)