So after almost a month's wait I was finally able to derive this conclusion proposed as an answer to my own question with the help from various sources:
1.) When using dynamic-update, Hibernate has to generate the corresponding SQL string each time and there is thus a performance cost on the Hibernate side. In other words, there is a trade-off between overhead on the database side and on the Hibernate side.
2.) Hibernate caches the actual SELECT, INSERT and UPDATE SQL strings for each entity. This results in not having to re-create these statements every time you want to find, persist or update an entity.However, when using dynamic-update, Hibernate has to generate the corresponding SQL strings each time. This results in a performance cost on the Hibernate side.
3.) Useful when applied to a very small & simple table as there is a significant performance gain using this annotation. A more realistic scenario, on wider tables using a remote database, performance increases may be more pronounced. Of course, the mileage you get out of this will vary most of the columns need to be updated.
4.) The @DynamicUpdate annotation/ dynamic-update=true is used to specify that the UPDATE SQL statement should be generated whenever an entity is modified. By default, Hibernate uses a cached UPDATE statement that sets all table columns. When the entity is annotated with the @DynamicUpdate annotation, the PreparedStatement is going to include only the columns whose values have been changed.
Overall could be summarized as:
1. Runtime SQL generation overhead.
2. No PreparedStatement(caching) used anymore.
3. Performance overhead.
Credits: Hibernate ORM 5.2.7.Final User Guide,http://memorynotfound.com/hibernate-dynamic-update-attriburte-example/,http://stackoverflow.com/a/3405560/1004631
P.S.: Also holds true for dynamic-insert=true/ @DynamicInsert annotation