The result of an unquoted arithmetic expansion undergoes file name globbing (wildcard expansion) and word (field) splitting, like any other unquoted expansion. It's pretty useless and a few shells don't do it but it's what historical shells did (because it was easier to implement) and so it's what POSIX standardized.
The result of an arithmetic expansion is just a string of
- and digits, so it can never contain a wildcard. (A few shells have floating point and can also include
+ and letters.) Since it can't contain whitespace, it is normally not subject to field splitting either. However field splitting is configurable through
IFS: the field separators are the characters of
IFS. Including digits in
IFS is extremely rare and is a pretty silly things to do, but if you want to write fully robust code, you need to protect against this. This matters more if the result may be negative, because including a dash in
IFS is not as silly.
POSIX states that the shell must set
IFS to its default value when it starts, so that scripts aren't affected by a value of
IFS that might be in the environment. (It's uncommon to export
IFS, but someone could do it.) However, some widespread shells (dash, Busybox sh) keep whatever value of
IFS is in the environment, so a robust shell script should set explicitly
IFS to its default value (or unset it, which has the same effect) if it contains any unquoted expansion.