Adding joint limits to a URDF is only the specification part. For these limits to be taken into account, you need an implementation that enforces them.
As you have already noticed, not all URDF-parsing implementations take the complete specification into account. The joint_state_publisher, for instance, takes joint names, types and position limits into account for publishing sensor_msgs/JointState messages, but does not not consider joint velocity limits. Also, there are certain specifications, like the maximum joint effort, that cannot be enforced with a kinematic-only implementation. So, the important thing is to understand the scope and limitations of an implementation, and a package's documentation should help here. I went ahead and added to the joint_state_publisher ROS wiki entry a comment to this effect.
As @lucasw mentions, you could consider using the ros_control framework for setting up your robot and move it with controllers that are aware of the complete URDF joint limits spec. You might find the joint_limits_interface package of particular interest. A more general discussion can be found on 24:14 of this video. Note that the overhead of setting up ros_control for your robot will be higher than setting up the joint_state_publisher, there's no free lunch.
Are you using the joint_state_publisher gui slider? I haven't used it in a while but those bypass the velocity limits. You need a controller in operation to respect velocity limits, and then you would be publishing commanded positions into the controller and then watch it work more slowly.
First of all, thank you for your answer. Yes, you are right, I'm using the joint_state_publisher gui sliders, I did not know it bypasses the limit. So, how I could implement this controller in operation? Is there any package to make it, or to make it easier? Thanks!
I've only used the controllers with gazebo following http://gazebosim.org/tutorials?tut=ro... and https://github.com/ros-simulation/gaz... - the controllers can be used outside of gazebo to connect to real hardware, but without real hardware you would need a sim.
Take a look at http://wiki.ros.org/ros_control?distr... also.
Aha! Ok, I understand what you mean. We are assembling a robot, so the idea was keeping the simulation near to the robot and watch both. So, it's better if they move in a similar way. Thank you very much, I will try it.