so what are you trying to suggest here?
the number of transactions in that block is 230 because people (services) have been batching transactions and reusing addresses which has led to creating bigger transactions hence taking up bigger space in a block hence a block being able to contain lesser number of them.
this has been the case from day 1 and will be with or without SegWit or even with having a hard fork to a block size 2 MB.
what you notice is that the bloated "batch" tx's are using segwit smart contracts which batched up 200 inputs and 1 output
with a 65kb bloat per tx
if an exchange used 200 legacy addresses
in*180 + out*34 + 10
200*180 +1*34 +10=36044
so using segwit. actual hard drive bytes are 65kb.. vs legacy would have been 36kb per tx..
meaning less actual hard drive bytes would have been used by that block 230 txs.
now imagine it was legacy, and no witness scale factor and the legacy cap was 2.3mb(to keep the block the same hard drive bytes used limit as the block exampled).. more than 230 tx's would have fit in
now imagine 4mb legacy cap without the segwit witness scale factor to make the 4mb weight fully utilisable. even more transactions would have fit into a block..
it aint rocket science