Your preferred methods of data handling are entirely out of the scope of the library (and Specification). If you’re dealing with a large number of ports, declarative approaches based on a handler registry might be preferred, where you define a dictionary mapping port-ID to handler functions, and traverse it whenever you receive a new transfer. Up to you.
No.
A port-ID identifies a specific service within the system, like, say, airspeed measurement, or a radar sensor, or a motor drive. The service requires a data type definition to facilitate data transactions. A data type may be used with different service instances (e.g., multiple cameras) or even completely different services (e.g., the same type can be used to report an estimation and to command a setpoint). Excepting few edge cases, most of which are already addressed by the standard data type set (uavcan.*), data types defined by vendors/developers will not need a fixed port-ID at all. Instead, the mapping between subjects/services and their identifiers will be established according to the design of the system at a later stage. As I wrote earlier, it helps to reason about subject-IDs as topics, they are basically identical in their purpose.
There is a short explanation in Choosing Message and Service IDs. If you are building a UAVCAN-powered system, you really need to read the Guide, where this question is explored in-depth.