as unbiased as i can be
segwit works not by simple activation. but by moving funds long after activation to new keys that allow part of a tx's data to safely sit outside the native(normal/base) bitcoin block.
to achieve say 1.1x(1.1mb) scaling of the tx count requires ~10% of transactions inside the native block to be using segwit keys to allow and allowing more space within the native block
as you can see by this. where the yellow is the old native key use. and the grey is the new segwit key use to achieve ~2mb of data and ~2x tx count
dynamics works not by simple activation. but by allowing the native(normal/base) block to grow passed its old 1mb limit to allow in more transactions. without users needing to move funds to new special keys
in reality this wont be an overnight sudden jump to 2mb. pools and nodes would test the water in small increments to see the orphan and unsync node risk/count. and if deemed safe the consensus mechanism keeps the new increment and then steadily grows over time, based on how safe it is to do so
as you can see by this. where the yellow is the old native key use.
there are some pro's and cons of each
currently editing pros and cons to address OP's questions, (trying to be as unbiased as i can(but hard to achieve))
segwit pros
*if 100% of key utility inside the base block will be segwit. then those using segwit keys cannot perform sigop, maleation, .. and it offers extra tx count
*non segwit nodes get trimmed data (lacking signatures of segwit tx's outside native block). allowing them to connect as second tier nodes downstream nodes but are not part of the full validation/syncing network.
*expect if 100% segwit key utility, an average of 2mb of full untrimmed data. (based on current natural healthy lean-ish tx's stats)
segwit cons
*100% of key utility inside the base block will
not be segwit! native key are not prevented and can perform sigop/bloat attacks bringing down tx count
*non segwit nodes get trimmed data (lacking signatures of segwit tx's outside native block). becoming second tier nodes that are not part of the full validation/syncing network. but connected as downstream nodes
*non segwit nodes need to completely rewrite the entire implementation with thousands of lines of code to be segwit validatable/ full syncing
*expect untrimmed blocks to be less than 2mb if native attacked, more if segwit bloat attacked
*if there was a bug/exploit requiring downgrading. those funds on segwit keys become locked and unspendable if no chance to move back to native keys before downgrading
dynamic pros
*grows the blocksize without users needing to change to different keytypes
*compatible with several diverse implementations but not core.
*core require only rewriting a few lines of code to stay part of a dynamic network
*if there was a bug/exploit blocks are simply made at under 1mb and dont require users changing keys/moving funds/having funds locked
dynamic cons
*not compatible with core.
*non dynamic accepting nodes fall off the network completely once dynamics reach the limits non dynamic implementations have set