Addresses and ports have different roles
Protocols such as TCP and UDP use 16-bit port fields to distinguish communication endpoints. IPv4 itself has no such port field; an address-and-port endpoint combines information from different layers.
A port value also needs its transport context. The same number under TCP and UDP does not erase their different semantics, and local address, peer and protocol help distinguish communication rather than one bare number doing all the work.
Registry ranges differ from runtime allocation
RFC 6335 divides the registry into System Ports 0–1023, User Ports 1024–49151 and Dynamic or Private Ports 49152–65535. Assignable ranges include assigned, unassigned and reserved values, while IANA does not allocate dynamic values to fixed services.
These are registry rules, not a promise that every operating system chooses ephemeral ports from exactly the same boundaries. Binding policy and configuration determine actual allocation; a registry is not an inventory of services currently listening on a machine.
A familiar number does not authenticate a service
Service-name and port assignments support conventions but do not prove that observed traffic implements the registered application. An application may use another allowed port, and protocol identification can require actual negotiation or data.
RFC 6335 states that allocation is neither product endorsement nor certification of good traffic. Firewall policy, service authentication and application authorization need their own basis; an allowed number does not make its contents trustworthy.
References: [1]