You're generalizing too much. 1 and 2 are actually internal products and should be planned and budgeted out by higher-ups as projects. I have no idea what would constitute #4 the way you describe it, but it sounds like a business requirement that should also be dealt with as a project or internal feature. Lastly, #5 is business continuity and a primary function of IT in general.
This leaves #3 as a sector where the manual/automation see-saw can be improved by tooling. The others are more aspects of business that do not happen otherwise. Tooling is more concerned with easing the jobs of people who implement the thing being streamlined with the tool. In a sales context this would be something like switching to a shared address book or whiteboarding an in/out scheduling chart, both of which they can do for themselves. Interdepartmental deliverables are not tooling.
I think he was actually fair spot on, I work on an "Internal Tools" team, and we do #1 - #4, in addition to maintaining the bug tracker, finance and audit tools, and a translation/review product. #5 is definitely DevOps though.
You both may be right in terms of the semantics and divisions of labor in your respective companies/experiences, but they are more general than the historical sense of tooling in a systems context.
This leaves #3 as a sector where the manual/automation see-saw can be improved by tooling. The others are more aspects of business that do not happen otherwise. Tooling is more concerned with easing the jobs of people who implement the thing being streamlined with the tool. In a sales context this would be something like switching to a shared address book or whiteboarding an in/out scheduling chart, both of which they can do for themselves. Interdepartmental deliverables are not tooling.