The lag introduced by a good blueprint implementation is no more than a frame compared to C++.
The main problem is that the client is on the other side of a network from the server. If you want to reduce the lag as much as possible, the client and server need to be wired to the same wired network, and you have to make the network tick rate faster than the frame rate, and make sure you set all your important objects (clients) to have the appropriate very-high network update frequency.
In general, though, physics based on direct client interaction will always be laggy, because of the various asynchronous steps involved (client input, client simulate, client render, network packet building, network transmission, network receive, server simulate, server render) which all may cause delays that end up accumulating. The only solution is to design your game rules such that latency is hidden, and implement your game animations such that the other players don’t notice.
My favorite in hiding latency, is the “yes, sir!” animation that units play when you give them orders in RTS games, before they move out. That animation is only played for players that give the order, and by the time the animation/clip has played out, everybody has the command/message, and the unit can actually start moving. This extreme measure is absolutely needed by RTS games that use lockstep synchronization, and the same mechanism can also be used in interpolated engines like Unreal, although the outcome in Unreal if you miss it is just that objects look laggy, not full game de-sync like you’d get in a RTS game.