Yes, CTR (resp. OFB) mode first "encrypt the nonce" then increment it (resp. replace it by the result of the block encryption), and repeat, producing a keystream; the plaintext is just XORed with the keystream, forming the ciphertext. In effect, CTR and OFB are stream ciphers made from a block cipher.
- Decryption and encryption are the same.
- For AES, which block decryption in software is inherently more compute-intensive than block encryption, that reduces the cost of decryption.
- There is no need to pad the plaintext to block boundaries; it's enough to truncate the keystream.
- It's possible to produce the keystream before the data is available, allowing a reduction in encryption/decryption latency.
- For CTR, preparing the keystream is parallelizable. Contrast with CBC, where encryption must be sequential (beside requiring availability of the data).
The only drawback is the malleability of ciphertext (meaning toggling a bit of ciphertext toggles only the corresponding bit in the deciphered plaintext), inherent to stream ciphers. But malleability is a non-issue with authenticated encryption modes like AES-GCM (which uses CTR mode for encryption), since relying on the feeble integrity properties of CBC mode is a recipe for disaster anyway.