Yeah, and the only reason they don't static link is because these dylibs are some 3rd-party closed-source libraries to avoid a lot of version clashes comparing to ship static lib naively.
Otherwise you put some code in dylib so your app extension can share some code with the main app, but that is tricky due to different RAM usage restrictions between app extension v.s. main app.
For example: https://tailscale.com/blog/go-linker/ talks about how they slim down the Go runtime to workaround the 15MiB memory limit for network extension.
Yeah, I am not explaining myself very well. I meant: people try to sharing code between main app and extensions with dylib. If they don't do that, they have code-duplication in the app bundle so the binary size is main code + 2 * shared code + extension code. However, it becomes more complicated because if you just naively sharing the code, your sharing part will be bloated, therefore, making the RAM usage higher than a static linked one (because static linked sharing code can do dead-code elimination better).
Otherwise you put some code in dylib so your app extension can share some code with the main app, but that is tricky due to different RAM usage restrictions between app extension v.s. main app.