Big rules like "you should never configure portfast on a trunk" are meant to be simple and safe. It is however not very precise, and are not really useful when the concept behind is really simple, as it is in this case.
The only relevant question is whether the port you are connecting can introduce a bridging loop.
*If yes, then you'd rather leave STP run unmodified and don't configure portfast. Note that, as it was mentioned in this thread, a port connected to bridge that is not introducing any redundancy in the network could in theory be configured with portfast. I would personally not recommend it because the advantage is not worth the potential trouble. That's however a decision (and a risk) you could perfectly take as an advanced user.
*If the device cannot introduce a bridging loop, then you can configure portfast. With RSTP and MST, if you want to benefit from the fast convergence introduced by those protocols, you *should* configure portfast. Layer 3 devices (routers, hosts) are safe and can be configured for portfast.
The port that you configure with portfast is an edge port in the IEEE terminology. Edge vs non-edge makes much more sense than trunk vs access. Cisco's terminology is actually not appropriate at all. It comes from the days when the only trunking technology was Cisco's ISL and that a trunk port was necessarily going to a Cisco switch (thus non-edge) while hosts (that did not understand ISL) were necessarily connected to an access port.
Edge = access vs trunk = non-edge is not valid any more (and was in fact never valid). 802.1Q being an IEEE standard, any PC can be trunking nowadays. Routers can have trunk interfaces to a switch. A PC and a router are edge devices. You should configure portfast on them (the command has been introduced under "portfast trunk" as a fix to this wrong terminology). On the other hand, as it was also mentioned in the thread, you can perfectly connect two switches using an access link and create a bridging loop in your network.
So forget trunk and access, just think about edge and non-edge.
Uplinkfast and backbonefast are not relevant to RSTP or MST, that have the equivalent functionality built-in. Again, if you run Rapid-PVST or MST, make sure you correctly identify edge port and configure portfast on them.
Enabling bpduguard by default on portfast port would not be a good idea for at least the two following reasons:
-1-Bpduguard is a proprietary feature and was introduced after portfast. We just could not change portfast's behavior by enabling it by default as of a certain release. Note that you can configure "spanning-tree portfast default" in the global configuration mode to achieve this if you wanted.
-2-Bpduguard does not prevent a temporary loop that would be the result of a misconfiguration of portfast.
When you configure portfast on a port, you don't disable STP, you just make this port moving to forwarding immediately. If you made this misconfiguration on both ends of a redundant link, you will effectively end up with a temporary bridging loop until a single bpdu is exchanged between the two ports. As soon as STP detects the loop, it blocks one port. If you configure bpduguard, the exact same temporary bridging loop would occur, the only difference is that when the loop is detected, the port is shut down. That's just a different policy you apply as a result of receiving a BPDU. BTW, bpduguard is not very subtle because it will shut down the port if it receives a bpdu, even if the link is not introducing a loop in the network. For instance, if you connect two switches with a single link and configure portfast on both end of this link, nothing bad happens (as it was mentioned in the thread). If you configured bpduguard, the link goes down, which is relatively bad in one way (but gives you a warning on the other hand).
