It gives us access to more tools in OTP, such as erl_eval, cover, debugger, etc. In the past, even Dialyzer required abstract erlang, but I have fixed it a couple releases ago.

I would strongly recommend that you use the Erlang abstract format. It will always be better supported by the OTP team and will have fewer compatibility issues.

For example, in OTP 23 we improved the syntax for binary matching. To do that, we had to change how we generated Core Erlang. We stopped using the receive construct in Core Erlang and started using new low-level primops for handling the mailbox. The changes were not in violation of the Core Erlang specification, but it broke tools that depended on the old implementation.

As @bjorng mentioned sometimes the translation from Erlang AST to Core erlang changes which can cause confusion. I had such problem before with LFE when I generated Core. I was generating guards very simply and naively, though correct, and in one version of Erlang one of the optimising passes decided my guards should just fail. Which is not quite what I had intended.

So generating Erlang AT is safer and more future proof.