Although security is a side effect of using WASM instead of DLL’s, the main reason this was done is so add-ons would be able to be cross-compatible with the XBOX platform, which requires a sandbox.
Porting over planes from P3D should not be Herculean task, especially when it comes to coding. If you don’t want to take my word for it, read Mathijs Kok’s thoughts here. If I were to give a rough estimate, I would say the SDK is 95% complete. You can read and write files, you can send and receive data over the network, you can interact with simobjects, etc.
So, if you wrote good, well-documented code for P3D, you should be able to port it over with almost all of the same functionality in MSFS. The issue arises when certain payware companies developed their addons with complex workarounds and hacks tailored to P3D, and expect MSFS to launch with support for these systems. It makes sense from a business standpoint for them (less money spent on development time) but in my opinion, it is NOT beneficial to the MSFS developer ecosystem as a whole. It encourages outdated development practices and reliance on old FSX-era code.
Personally, I would have wished if MSFS started from a blank slate and didn’t use any of the FS2004/FSX ESP (Enterprise Simulation Platform) API’s. They restrict a lot of development possibilities. Overall, the times are changing, and the ones who adapt the fastest will be the winners, and the first to market.