Hi,
It is difficult to provide a complete list of all downsides of configuring an end device's port as a trunk. However, these are some of the points to think about. In all of them, it is strictly assumed that the connected device is not a switch.
First of all, a trunk by definition carries data of multiple VLANs. If you subsequently limit the list of allowed VLANs to just a single VLAN using the switchport trunk allowed vlan then the entire configuration is a gross waste of effort. You have declared the port to be capable of carrying data from possibly all VLANs at once - and then you tighten it down to just a single VLAN. The whole point of a trunk would be lost by that.
Furthermore, if you allow more than one VLAN on such a trunk port, the frames sent out that trunk port would be tagged (except frames in the native VLAN). On a trunk with N allowed VLANs, at least N-1 VLANs will be tagged. The device on the other end, however, will not understand and process tagged frames unless specifically and explicitly configured to do so. So again, this is a waste of effort, as out of N allowed VLANs, at least N-1 of them will have their traffic sent out needlessly and discarded (or even worse, misprocessed) by the attached device.
Yet continuing, even though the attached device may not understand tagged frames, it nevertheless has to process them - at least the broadcast frames, as the MAC addressing is not affected by tagging. This is an important point: Even though the attached device may not understand tagged frames, it will nevertheless pick up and preliminarily process all broadcast frames, no matter what VLAN they are in. Its CPU will thus be bothered by unnecessary broadcast traffic combined from all VLANs allowed on the trunk.
Even worse, though, if the attached device was maliciously compromised so that it would be able to process and understand tagged frames, then by the virtue of being connected to a trunk, it would become able to communicate in all VLANs allowed on that trunk. The end results could be catastrophic: Maliciously bridging the VLANs together, possibly causing a switching loop; directly attacking resources in all allowed VLANs; circumventing security policies by reaching remote networks over unexpected VLANs; impersonating any chosen station in any VLAN including a gateway or a DHCP server; wreaking havoc by having direct access to all allowed VLANs and being able to send whatever frames into them.
From the viewpoint of a switch, a trunk port even with a single allowed VLAN is still a trunk. That means that some of the mechanisms that act by default on access port won't act on trunks. That goes for PortFast, for example, and if you're running RSTP or MSTP then for uninterrupted connectivity of end stations, PortFast ports are of paramount importance. There were times when Port Security could not be configured on trunks, although that limitation has long been lifted. I am not sure about the current state of support of certain other security mechanisms on trunk ports, such as 802.1X. We could go on and on regarding the changed behavior of trunk ports as opposed to access ports (running VTP, DTP, possibly processing CoS markings, originating and processing STP BPDUs, ...) but I am sure you get the point by now.
All in all, it is first and foremost a misuse and an improper application of the trunk port to have an end device connected to it. All negative consequences are the result of using improper means to achieve a specific goal.
As to why your configuration change as described above worked, I am frankly somewhat confused. The native VLAN before the change was 100, after the change, the only VLAN running over the now-to-be-access-port was 100. The connectivity of the device in the native VLAN should have not been impaired or improved by this change. I see two possible failure modes: Either the port was blocked for some reason (don't want to speculate now), or the printer was flooded by broadcasts/multicasts in VLAN 101 and got stalled as a result. We are lacking any diagnostic information at this point, though, to narrow down the possible cause.
My two cents...
Best regards,
Peter
