The key wrap algorithm can be envisioned as an extended Feistel scheme which uses AES as the round function, combined with a running state which serves as a rough MAC. If you look at the algorithm definition, you will see that for each of the s rounds, one 64-bit block of data is updated, with a combination function which includes an AES invocation and another 64-bit block. The blocks are also "rotated" so that the next round updates another block, and so on. This really is akin to defining a big block cipher operating over the complete plaintext as a single "block".
As symmetric encryption systems go, this one is quite inefficient, because it involves an average of 1.5 AES invocation per input byte (12 AES invocation for a 64-bit block), whereas GCM would use only 0.0625 AES invocation per input byte (one AES every 128-bit block). It also needs to process each input byte several times, so the entire plaintext message must be fully buffered: this will be inadequate for bulk encryption.
The key wrap algorithm was designed to protect keys and suffers from some ritualistic overkill: a lot of accumulated AES invocations on the hope that it will make so much scrambling that the result will be strong. This is not a bad bet; if we look at it as an extended Feistel cipher, then there is some empirical data that many rounds will bring security. This should deserve some decent analysis, though, and, to my knowledge, this has not occurred yet. This is probably related to the fact that this key wrap algorithm appears not to be much used in the wild.
Good properties of the AES key wrap algorithm include the following:
It does not need randomness. Randomness is a scarce resource on many embedded systems, so having a scheme which is secure without it is nice.
It does not need state. No EEPROM or Flash bit to modify, if only to keep a counter.
It is deterministic. This means that wrapping the same plaintext with the same key will yield the same sequence of bytes. Determinism is mostly neutral, but occasionally useful in some protocols.
It uses a single primitive, which is "the AES": code size is also a scarce resource on embedded systems.
It has low size overhead: it adds only 64 bits to the input size, and includes a MAC, so that's about the smallest than can be achieved.
Bad properties are mostly these ones:
The algorithm is inefficient, with a high CPU cost per byte, and the need for full buffering. This is why the algorithm is meant for key wrapping, where "keys" are short entities, keeping the wrapping costs under reasonable limits.
Despite its 12 years, the AES key wrapping algorithm did not benefit from a lot of analysis or even attention from the cryptographic community, probably because of its restrictive use cases.
