Stream cipher and block cipher usage in network data encryption Stream ciphers are usually used for streaming data encryption, such as voice, and also for low layers data encryption. For example, MACSec uses AES-GCM encryption.
In L3 ad L4 security protocols (IPSec and SSL) block ciphers are preferred (AES-CBC).

Why are stream ciphers considered to be better than block ciphers in low layer encryption and block ciphers considered to be better for higher-level encryption?
What makes voice data (which is application layer data) suitable for stream cipher? Isn't it easier to divide the voice stream into blocks and encrypt it with block cipher?
In L3 ad L4 security protocols (IPSec and SSL) block ciphers are preferred (AES-CBC).

Errr, no.  Originally, SSL used RC4 (which is a stream cipher); then CBC mode (first DES/3DES and then AES) was added.  In the latest version (TLS 1.3), they discarded RC4 and CBC mode entirely, in favor of AEAD modes (GCM and Chacha20/Poly1305).
As for IPsec, it was originally CBC mode only (first DES/3DES and then AES).  Later, they added AEAD modes, and I believe they are currently the most common.
Hence, your claim that AES-CBC is preferred is not currently accurate, and so the assumptions behind your first question is not relevent.
Your section question is still interesting:


What makes voice data (which is application layer data) suitable for stream cipher? Isn't it easier to divide the voice stream into blocks and encrypt it with block cipher?


With voice, they tend to be quite sensitive to encryption overhead; the VoIP packets themselves are quite tiny (circa 20 bytes on average, IIRC), and so a fixed amount of overhead would be a larger fraction of the total overhead than, say, in TLS.  In addition, VoIP often goes over wireless, and they are especially sensitive to bandwidth there (in large part because of power; transmitting more bytes uses more power).  What this means is that VoIP encryption protoocols (such as sRTP) are designed to minimize encryption overhead over just about any other consideration.
Hence, modes that require padding (such as AES-CBC) would be rejected outright, in favor of modes that don't (such as AES-CTR).