Serpent is straightforward to implement with side-channel resistance due to the bit-sliced design. Because AES incorporates an S-Box that is most simply implemented as a lookup table, implementations of it tend to be prone to side-channel attacks.
Threefish was designed for the SHA-3 competition, and was intended to be a part of a sort of package of cryptographic primitives, including encryption, hashing, and a MAC. If you wanted a crypto library that didn't require implementing a whole host of different algorithms, Threefish might be a good choice.
One compelling reason to use AES is that many modern CPUs support the AES-NI instruction, which will make encryption with AES almost certainly faster than any other algorithm. A faster algorithm is mostly always better, but unless you are encrypting large amounts of data you will likely never even notice the difference. It might save a couple of cents on your power bill since AES-NI requires fewer CPU cycles.
Of course, as a user, these implementation details may be invisible. And the libraries you mentioned already implement a whole host of different algorithms, so that advantage is negligible in the situation you are concerned with.
Offering multiple options is generally better than a single option (within reason - too many choices is bad). It's a bit like asking why a restaurant has more than one item on the menu. Some people might not care for that one item, for arbitrary reasons.
For a point-by-point overview of why Rijndael was selected as AES instead of Serpent or Twofish, you can investigate these other related questions