The OAuth scopes operator asks for are the following: chat:write:bot - so we can post to your channel operator's response. commands - to install the commands. users:read - so we can get a bit more information about you (name, team permissions, etc).
We even toyed with the idea of eliminating the "users:read" to be as minimally invasive as possible.
We use Slack in a company of ~30, and while all the devs could easily use IRC, most of the rest of the company would struggle with it, and certainly wouldn't be able to communicate in the wide variety of ways (uploaded files, images/gifs, videos, code snippets, etc) that they do now. Slack is great at making all those rich media types 'just work', and while it was possible with plugins to some IRC clients, the UX was prohibitively bad in my experience.
>(uploaded files, images/gifs, videos, code snippets, etc)
Slack is really just a rich-text jabber client.
"Use IRC" isn't a very strong suggestion for a business, what really gets me is seeing open source projects using slack. I even had a casual IRC channel I used to frequent migrate to slack, smh.
You might also want to check out the settings in the Messages & Media section, specifically "Expand links to images, video and audio from external sources". That might help to disable the inline GIFs, although I haven't tried it myself.
I've often toyed with the idea of writing an IRCD with logging built in that drops all CTCP setup messages, but it's a huge hassle.
[1] https://www.inspircd.org/ [2] https://github.com/joshenders/inspircd-m_chatlog
Slack, Hipchat and others however can be easily set up and used by pretty much anyone in a company. IRC is great for companies which only have very technically proficient employees, however that's not most companies...
I'd be curious to see how many companies would actually allow a 3rd party service to have that full amount of permissions. It's sort of like GitHub and how some services require the access to private repos. I'm not sure of a solution, but am just curious how it really holds back awesome services like this when companies don't feel comfortable giving it the level of access it has to have (but may not use that full access).