And yet you should use it in practice!

Hybrid encryption schemes are actually a good thing in practice, because they have many nice features. Firstly, notice that when doing hybrid encryption, we have two main components:

• a Key Encapsulation Mechanism to protect the key, in this case the ABE scheme
• a Data Encapsulation Mechanism to protect the data, in this case AES

And the encryption works by generating at random a key $\mathcal{K}$ that is used to encrypt the data $M$ using the DEM algorithm $DEM_\mathcal{K}(M)$, and then that key $\mathcal{K}$ is encrypted using the KEM algorithm for the public key $P_k$ of your choice $KEM_{P_k}(\mathcal{K})$, and the resulting ciphertext is the tuple $\left(KEM_{P_k}\left(\mathcal{K}\right), DEM_\mathcal{K}\left(M\right)\right)$.

A really nice property of the KEM-DEM construct is that if the DEM and the KEM are both "CCA2-secure" (secure against adaptative chosen ciphertext attacks), then the resulting hybrid encryption scheme is also CCA2-secure.

Whereas, for instance, if you were to encrypt a longer message than what your public-key algorithm allows, and decided to do so by "chunking" the message into "blocks" of the right size, and then encrypt using ABE each block of your message and send all the blocks together as you ciphertext, your scheme would trivially not pass the "CCA game" as we commonly use it, whereas if you were to use a CCA2 ABE scheme as a KEM and AES-GCM (or any other IND-CCA2 stream cipher) as a DEM, then you would still pass it.

For more details, including a proof of the former, I refer you to this paper by Cramer & Shoup, section 7.3.

It is also interesting to see what are the necessary conditions on the security of your DEM and KEM in order to have secure scheme. This online paper by Herranz et al. (or the published one) has a good coverage of the question.

The other good thing with a KEM-DEM scheme is the fact that such schemes are significantly more efficient than pure public-key schemes, as soon as the message would require more than one public key operation invocation.

No, this is not required by Attribute Based Encryption (ABE), however it is a common practice to use so-called "hybrid encryption" when you want to encrypt data using public-key encryption, for multiple reasons:

• it sometimes avoids the need for padding of the message: if your ABE scheme works on messages that are of size 256 bits, for instance, then using a AES key of 256 bits fits naturally in that message space. (Although in practice you often have some rejection sampling to do because the whole 256-bit space is not necessarily the universe of the messages.)
• it allows to ignore the limits of the public-key encryption scheme you are using, that is the converse of the previous point: if you can only work with 256 bits messages but want to encrypt more than 256 bits, then you have a problem, whereas AES (with a good mode of operation) (or the underlying stream cipher of your choice) is not limited in the size of the data you can encrypt.
• probably one of the most important reasons: the performance! ABE (and more generally public-key cryptography) schemes are super slow in practice, while AES is super fast, so in order to have decent performance it makes sense to use as little public-key cryptography as possible.

No, this is not required by Attribute Based Encryption (ABE) itself.

However it is a common practice to use so-called "hybrid encryption" when you want to encrypt data using public-key encryption, for multiple reasons:

• it sometimes avoids the need for padding of the message: if your ABE scheme works on messages that are of size 256 bits, for instance, then using a AES key of 256 bits fits naturally in that message space. (Although in practice you often have some rejection sampling to do because the whole 256-bit space is not necessarily the universe of the messages.)
• it allows to ignore the limits of the public-key encryption scheme you are using, that is the converse of the previous point: if you can only work with 256 bits messages but want to encrypt more than 256 bits, then you have a problem, whereas AES (with a good mode of operation) (or the underlying stream cipher of your choice) is not limited in the size of the data you can encrypt.
• probably one of the most important reasons: the performance! ABE (and more generally public-key cryptography) schemes are super slow in practice, while AES is super fast, so in order to have decent performance it makes sense to use as little public-key cryptography as possible.

So in the end, most practical instantiations of ABE (not that I'm aware of any) would be probably better off using ABE as a way to broadcast keys to access symmetrically encrypted data, à la Attribute Based Broadcast, rather than encrypted messages directly, excepted if the messages are really short!

As it wouldn't better to use hybrid encryption on message of the same size as the keys of the underlying symmetric cipher.

But to sum it up, in the end, there is nothing that restricts you and says you have to use hybrid encryption when using ABE. As long as the ABE scheme you are using is okay encrypting messages of the size you need to encrypt, then you could use ABE directly on the messages and it would not reduce the security of the ABE scheme when compared to a construct where you'd use hybrid encryption to first encrypt the message with a symmetric cipher with a randomly generated key, say AES, and then use your ABE scheme to encrypt the random symmetric key for the set of attributes that are allowed to access that message.