I don't know about the exact implementation, but just in terms of physics, if you want to turn without moving you do need torque and no resultant force. The torque turns you, and the resultant force moves you, so by definition what you want is just torque. You can get that using a pair of forces, but you need to make them push in opposite directions, on either side of the center of mass (I think), which is exactly the same as torque. So it seems like you might as well have the torque since it works out the same. Also a torque shouldn't instantly turn the vehicle, it will start it spinning at a rate depending on the moment of inertia and applied torque. If you want less turning at higher speed, you could just reduce the torque at higher speed, but I'm not sure why that helps - from the player's point of view it might just feel odd that the turning is "sluggish" sometimes. I can't think of any reason why any given vehicle would turn slower at higher speed. Unless the implementation you are talking about uses some kind of vectored thrust shared between turning and moving? In that case, it may not be capable of turning in place, or it may have pairs of thrusters. For example if a ship has a thruster on the nose, and one on the tail, it can turn by firing one left and one right with equal thrust - it will then turn in place either left or right (turns in direction the tail thruster is firing). It would accelerate forward by firing both thrusters backwards, etc. In this case, to accelerate and turn the thrusters need to be angled slightly, and the more forward acceleration you apply, the less turning you can get (and vice versa), which is maybe what you are after. In this case, you need to either let the player control the two thrusters, which will be really confusing, or implement a control scheme that translates the user's commands into thruster angles and forces, which will be complicated for you and still quite confusing for the player It would look cool though if you display the thrusters I hope some of that makes sense - I've not used jme-physics all that much, but I'm just describing how things work for a real physical system (I hope).
With the speed thing - if you want a maximum speed, that would tie in well with giving the player a fixed forward thrust to play with, but increasing the drag linearly or with the square of the velocity - you should then get a "terminal velocity" where the thrust balances the drag, without having to have an artificial limit where the thrust just turns off for no reason. You can do the same for torque and angular velocity to stop the ship spinning too quickly. You can tweak the response by altering the drag and force - you can achieve the same terminal velocity with a low drag and low force, or a high drag and high force, but the first will slowly approach the terminal velocity, whereas the second will get there quickly. I think classic asteroids works as if it had a very low force and drag for movement, and a very high drag and force for rotation, since I think the rotation was just a simple linear rotation rate thing.
Actually this discussion started me thinking about something - in jme-physics, when you apply a force, I get the impression it is cleared on the next update? Does this mean that you have to apply really large forces so that 1/100th of a second of that force is enough to do something? or are the forces really more like impulses?
Sorry for the huge essay, this is also stuff I've been through for my game so I've thought about it a lot I looked at using physics to control my planes, but ended up using a hybrid system with physics for collisions and "arcade" logic for movement when not colliding, since I really wanted to keep the sharp, easy-to-control feel of very simple arcade controls. When you hit something, physics makes sure you bounce off it until you regain control, but most of the time the physics object just follows the arcade plane around checking for collisions. Probably a horrible abuse of physics, really