Should RSA public exponent be only in {3, 5, 17, 257 or 65537} due to security considerations?
There is no known weakness for any short or long public exponent for RSA, as long as the public exponent is "correct" (i.e. relatively prime to p-1 for all primes p which divide the modulus).
If you use a small exponent and you do not use any padding for encryption and you encrypt the exact same message with several distinct public keys, then your message is at risk: if e = 3, and you encrypt message m with public keys n1, n2 and n3, then you have ci = m3 mod ni for i = 1 to 3. By the Chinese Remainder Theorem, you can then rebuild m3 mod n1n2n3, which turns out to be m3 (without any modulo) because n1n2n3 is a greater integer. A (non modular) cube root extraction then suffices to extract m.
The weakness, here, is not the small exponent; rather, it is the use of an improper padding (namely, no padding at all) for encryption. Padding is very important for security of RSA, whether encryption or signature; if you do not use a proper padding (such as the ones described in PKCS#1), then you have many weaknesses, and the one outlined in the paragraph above is not the biggest, by far. Nevertheless, whenever someone refers to an exponent-size related weakness, he more or less directly refers to this occurrence. That's a bit of old and incorrect lore, which is sometimes inverted into a prohibition against big exponents (since it is a myth, the reverse myth is also a myth and is no more -- and no less -- substantiated); I believe this is what you observe here.
However, one can find a few reasons why a big public exponent shall be avoided:
Small public exponents promote efficiency (for public-key operations).
There are security issues about having a small private exponent; a key-recovery attack has been described when the private exponent length is no more than 29% of the public exponent length. When you want to force the private exponent to be short (e.g. to speed up private key operations), you more or less have to use a big public exponent (as big as the modulus); requiring the public exponent to be short may then be viewed as a kind of indirect countermeasure.
Some widely deployed RSA implementations choke on big RSA public exponents. E.g. the RSA code in Windows (CryptoAPI, used by Internet Explorer for HTTPS) insists on encoding the public exponent within a single 32-bit word; it cannot process a public key with a bigger public exponent.
Still, "risks may be great" looks like the generic justification ("this is a security issue" is the usual way of saying "we did not implement it but we do not want to admit any kind of laziness").
The developers are simply incorrect. There's nothing wrong with the exponent 0x4451 (decimal 17489); it doesn't create any security problems.
Long ago people used to think that small exponents were a problem, because of an attack that Thomas Pornin explained with sending the same message to multiple recipients. But today we understand that the exponents had nothing to do with it; the issue was improper padding. Those attacks are prevented by proper use of padding. Any crypto library worth its salt had darn well better be using proper padding (otherwise you've got far worse problems).
So there is no good reason for a crypto library to flatly forbid use of that exponent.
That said, from a performance perspective, the smaller the exponent, the better the performance. The best choice is e=3, because that gives the best performance and has no known security problems. (Actually, e=2 is even a bit better. It is also known as Rabin encryption. However, that scheme is not as well known and requires slightly different code, so it is not widely used.)
Those five numbers are Fermat primes.
Since they are of the form 2k + 1, encryption is me = m·((m2)2...k times...)2, which is simpler and faster than exponentiation with an exponent of a similar size in the general case.
Since they are primes, the test that e is coprime to (p − 1)(q − 1) is just a test that e doesn't divide it.
So this is more likely about speed or convention than about security. Not that there's anything wrong with being efficient. But to be sure, do ask for a reference as the other answer suggested.
Also see this post.