Given my experience, I would not recommend using Wasmer over an alternative like Wasmtime for several reasons.
1. Lack of support for `externref`, AKA opaque references to host data. Sure, the Wasmer 2.0 blog post _claims_ they added support for it, but that amounts to allowing you to read the type signature in an existing module, but not actually use the feature yourself. With some digging, my educated guess is they wanted this to be their headlining 2.0 feature but weren't able to get it working, so they just pretended in their blog post and left the incomplete version behind a development flag.
2. An awkward context API for host calls. All host data associated with an instance must be `Send` + `Sync`. In practice I've found this leads to wrapping your entire context object in a `Arc>`, even if your data could otherwise live on the stack. Wasmtime does not have this limitation, so it's not a hard technical requirement.
3. It took me about 2 weeks of development to run into a use-after-free bug bubbling up into Rust.
4. The performance, at least for my use case, was not meaningfully better than Wasmtime. This may not be true if you're doing a lot of intense number crunching.
5. Lack of support for instance resource allocation pools. Wasmtime allows you to pre-allocate / reuse the resources associated with an instance, whereas you would have to roll this on your own with Wasmer.
6. Lack of support for the module linking proposal. This proposal may be incomplete, but it is still helpful ahead of its replacement.
This is on top of, as others have mentioned, their questionable business practices[1][2].
All of this may improve, but as things currently exist, Wasmtime should give you everything you would want from Wasmer in a more stable, more complete and more ergonomic package.
I believe the linking proposal is dead for now and replaced by the component model: https://github.com/WebAssembly/component-model
The wasmtime implementation is in progress.