Your screenshot doesn't show the situation you describe in your question text, but what you're seeing is most likely the effect of the joint2-joint3 joint coupling that some ABB robots have.
That coupling influences the joint position values reported by the RAPID runtime to the ROS driver (ie: the values don't actually correspond to the real-world angle of the joints), so the ROS driver has to compensate for that, if configured to do so. All launch files distributed through the ros-industrial/abb and ros-industrial/abb_experimental repositories set the J23_coupled launch file argument (here, for the IRB 120 fi), which gets passed on to the abb_driver nodes (here). Finally, that value is used to calculate the corrected joint angles for joint_3 (here). Both JointStates (here) and JointTrajectoryPoints (here) undergo this compensation.
So in the case of your screenshot: joint_3 (compensated) would be joint_2 + joint_3, or 0.092507.. + 0.328967.. ~= 0.421474...
Now whether this is correct for your IRB 140 depends on whether that robot has the same joint2-joint3 coupling. I've never worked with one, so I can't tell you. You'll have to (en|dis)able the J23_coupled parameter and see what the effect is on your simulated robot. Easiest is just to start the robot_state_visualize_...launch file and jog the robot in RobotStudio: RViz should show the exact same robot poses. You will very quickly recognise an incorrect setting for J23_coupled.
The fact that MoveIt trajectory execution already ''works just fine' seems to suggest that the value you currently use is correct though. But it's always good to make sure.
PS: if you are interested, you could install the packet-simplemessage Wireshark dissector, which will show you the JointTrajectoryPoint messages actually send by abb_driver (and received by your controller/simulator). Look for JOINT_TRAJ_PT and JOINT_POSITION messages. They should show the non-compensated angles.
