PKCS#5 (currently version 2.1) is written for block ciphers using 64-bit blocks, and is littered with references to eight octets, including in padding. However the principle that PKCS#5 uses for padding is easily extended to block ciphers with larger blocks (up to 255 octets per block), and that's what PKCS#7 padding is: for a message of $m$ octets ($8m$ bits) and a block cipher of $k$ octets ($8k$ bits), pad the message with $p=k-(m\bmod k)$ octets with value $p$. When $k=8$, that's precisely PKCS#5 padding.
AES is a 128-bit (16 octets) block cipher, thus (at least in CBC mode) it is not amenable to PKCS#5 padding as in it definition. The quote makes the simplest possible conjecture when it assumes that
AES/CBC/PKCS5Padding really is internally
AES/CBC/PKCS7Padding. Otherwise, it would be impossible to process some messages. For example, with strict PKCS#5, the 2-octet message
0x41 0x42 would be padded to 8 octets as
0x41 0x42 0x06 0x06 0x06 0x06 0x06 0x06, and that can't be CBC-enciphered with a 16-octet block cipher; the padding used by
AES/CBC/PKCS5Padding thus is
0x41 0x42 0x0E 0x0E 0x0E 0x0E 0x0E 0x0E 0x0E 0x0E 0x0E 0x0E 0x0E 0x0E 0x0E 0x0E.
Another plausible conjecture is that
AES/CTR/PKCS5Padding uses the same padding as
AES/CBC/PKCS5Padding, and is internally
AES/CTR/PKCS7Padding; but to be sure, we would need to look at the code or some test data, because CTR mode (contrary to CBC mode) does not require padding to block boundaries, and AES-CTR would also be compatible with no padding at all, or with strict PKCS#5 padding. According to this source, this varies across implementations, and it looks like the
Sun Oracle Java official stance is that
AES/CTR/PKCS5Padding is not supported, should raise an exception if used, and does so with few exceptions that are designated as bugs. Such important boring details are arguably off-topic.