Boyer cited the expense of of building and testing multiple codebases as one of the primary reasons his team ditched AMP. The complication of maintaining a second user experience was “far too much to ask” for his development team, who had already produced a fast, lightweight WordPress setup with proper caching.

Yes, this is a concern. And this is the key advantage of going the “Native AMP” route. By not using the paired mode—where there are separate AMP-specific URLs and even entirely separate templates—you only have to maintain one single codebase. You can just rely on AMP's own web components, like amp-carousel instead of also having to find something equivalent with some jQuery carousel plugin, for example. You can also just use amp-bind for developing interactive experiences where otherwise you would have to use custom JavaScript.

Nevertheless, the plugin's new paired mode is able to fully re-use your active theme's templates and styles. Since the AMP plugin does not allow any custom JavaScript, then the default behavior in this new paired mode is just as if JavaScript is disabled in the browser. So as long as you account for the “no script” users, then your site in paired mode will gracefully degrade even without porting your site's custom JavaScript to using the equivalent AMP components.