Ascon and ACORN both have interesting features. Let's discuss their pros and cons for some properties stated during the CAESAR competition for lightweight AEADs:
- Fits into small hardware area and/or small code for 8-bit CPUs
On this point, ACORN is more efficient as its internal state is smaller than the one used by Ascon (293 vs 320 bits). Moreover, thanks to its very compact core function, the code size of ACORN is smaller.
- Natural ability to protect against side-channel attacks
Regarding countermeasures against side-channel attacks, both algorithms are efficient. Ascon has been designed with bitslicing in mind, and thus can be easily implemented in a constant time manner. ACORN is also constant time by design as it does not rely on any conditional branch nor look-up tables. Regarding countermeasures against power/electromagnetic side-channels, 1st order threshold implementation can be reached using only three shares for both algorithms. However ACORN seems more efficient in hardware as stated in the paper you mentioned.
- Message sizes: usually short (can be under 16 bytes), sometimes longer
This is maybe the main advantage of Ascon over ACORN: it is way more efficient for short messages. This mainly comes from the fact that ACORN is a stream cipher that requires a huge number of steps to initialize its internal state. For instance, this paper reports (page 11) that Ascon outperforms ACORN for small messages (less than 128 bytes with 16 bytes of additional data) on ARM Cortex-M3. Ascon is also very efficient on 64-bit CPUs as by definition, its internal state consists of five 64-bit words. It is an interesting feature for use cases where high end servers have to handle numerous encrypted requests.
Finally, Ascon is based upon the duplex sponge mode whose security has been analyzed in several papers (e.g., https://keccak.team/files/SpongeDuplex.pdf and https://eprint.iacr.org/2015/541.pdf) while ACORN is based upon a new stream cipher construction. This probably influenced the final decision.
