The database contents for posts remain unmodified (easy install and uninstall).
Everything gets translated by default. If a post includes custom fields, they’re attached to that post, so they are already associated with the language.
Some plugins use – for theme’s displayed terms – the language files (.mo) delivered with localizable themes. In WordPress, localization is based in GNU gettext technology. So when a single post is in french, plugin switch all the terms of the theme in the same language (here french). The files can be completed with the specific terms of the site (categories titles, widget, links…). No need to re-translate all, just add specific terms and translations in target languages.
Other plugins that analyze contents (like related posts) keep working correctly.
More complex architecture. The plugin needs to hook to many WordPress functions and filter them so that only contents that matches the language is returned.
Additional tables are required by some plugins – normally, to hold the translation grouping. Newer plugins likely use a custom taxonomy or post meta fields instead.
May cause excessive database grow and slow performance as a result. A WooCommerce-based site having a 100,000 products will have 500,000 records after translating to 5 languages. All product metas (could be tens of those per product, and also transients will be duplicated, too, so the database might become huge).