extended_row_sz
is for lazy people who do not want to spend time designing their database for best performance. It was intended to enable the Oracle compatibility feature: the Oracle database does not have the row size limit and one would need to rewrite DDL for tables where row sizes exceeded the limit determined by the page size. After enabling the extended row size one would be able to run the Oracle DDL statements as is.
However, the row size limit in Db2 did not go anywhere. What happens after enabling the extended row size is that Db2 implicitly converts the data types of long character columns to CLOB if the total declared row width of a table exceeds the limit. It does so without telling you and without any performance optimisations that a careful DBA would be able to apply if they were to explicitly design tables to use CLOBs where necessary (LOB inlining and the LOB tablespace properties come to mind).
So, to answer your question about pros and cons of extended_row_sz
: it saves you some effort at the database design time, at the cost of potential performance problems, which are not very easy to diagnose and require database redesign anyway, in the future.