The Yubico AES mode does only work with a yubikey. The device returns a long data structure, that needs to be decrypted.
HOTP returns a 6 or 8 digit code. The algorithm uses a truncation to form the digit code. The digit code is created so that a user is able to read the code and type the code into a keyboard.
Thus: With Yubico AES mode you need to have a device that creates and inputs the one time password, while with HOTP you can always rely on the keyboard.
The Yubico AES mode increases two counters. A plug counter and a usage counter. This data is encrypted, then the encrypted value is sent for validation. Validation in this case means, that the encrypted value is decrypted and than the server verifies if the sent counters are bigger than the last counters, which the sever saw.
In HOTP mode the OTP value is calculated based on the counter. The server needs to perform the same operation like the OTP token. This is why you have this window thing. The token could be pressed without the value being sent to the server. The server knows the last value (counter=n) it saw. But it does not know, how many blank presses were performed on the OTP token. So the server needs to //try// n+1, n+2...
The HOTP token can get "out of sync". The Yubico AES mode can not.
Yubico AES mode is well documented. But it is only implemented by the Yubikey. HOTP is standardized in RFC 4226.
Well don't ask me. I suppose that both AES and HMAC-SHA1 are sill strong algorithms...
...now you can decide which aspect is a pro and which one a cons. Usually it boils down to usability and the question if you have a USB port or not. The yubikey is one of the few hardware tokens, that can be initialized and thus you can keep control over your key material. Use a open source backend lile privacyIDEA to enroll and manage the tokens.