Since this came up as one of the top results in Google, here's what I've found:
Mark service accounts as internal integration users (Yokohama)
The documentation indicates that this is specifically for SOAP requests as Mark mentioned. The explanation he left out is this:
"When WS-Security is enabled, authentication is required for all SOAP requests including internal integration communications such as the MID Server, ODBC Driver, Remote Update Sets, and high availability cloning. SOAP requests for these internal integration communications cannot implement WS-Security due to technical implications. If your instance uses these SOAP interfaces, you can allow them to bypass the WS-Security authentication requirement by marking their user accounts as internal integration users."
My interpretation of that is that it is a role designed for those specific features which ServiceNow has already implemented and do not support WS-Security (Yokohama). Other types of SOAP requests should be able to go through the WS-Security authentication process. (I've included Yokohama links because the latest-version feature seems to be down right now)
Knowing that, the only case for using that role is:
1) You are using SOAP
2) You are using WS-Security profiles with SOAP
3) The thing you're connecting via SOAP does not support WS-Security functionality
So the Internal Integration User option would actually decrease your overall security stance.
tl;dr: Don't use Internal Integration User. Do use Web Service Access Only.
