It applies to any task, but I think it would be unlikely to see an Input or an Output on a User (Human) task, since you would be defining the form specifically for that task.
However, it’s possible to use the same form over and over, so it might be done, especially if you have separation of responsibilities, where one team is managing the Forms and another is managing the process.
A Service Task is typically a program task, which could be configured by Connectors (eg. Making a REST call). Since the Connectors are explicitly designed to be reused a lot, they use predefined variables for what they want to receive and what they provide back, so it’s almost 100% chance that you will use Input and Output mapping on a Connector (The connector’s variable name won’t necessarily make sense in your workflow)
A Business Rule task is also a program task, usually implemented with a Decision Model Notation (DMN) diagram. These are usually made up of a table that contains Input Criteria and Output values. These can be thought of as a “Truth Table” and Parameters. If the Business Rule is “And” and you have two Input Criteria (boolA and boolB), then you would have 4 rows in your table:
a | b | Output
F | F | F
F | T | F
T | F | F
T | T | T
The Camunda Engine can evaluate the Business Rule (which can be a LOT more complex than “AND”) in a Business Rule Task, and provide the Output into the overall process as a Variable to be evaluated by one of the Gateways, or used in one of the User (Human) tasks.
Inputs are used to transform a Process Variable (a Variable that is used in multiple Tasks) so that the are in the form that is appropriate for that Task (or Job) to use. Outputs transform variables that the Task had into the form appropriate for the overall Process.