I didnt fully read up on loopdetect but this is what I got from the back of my head (anyone is free to refresh its contents
1) As far as I know loopdetect and STP can both be enabled at the same time.
2) Yes they can conflict because they doesnt know of each other. The drawback of STP are the system resources needed, potential way for a bad client to make trouble in the rest of the network and convergence time (stuff will stand still until a new tree is calculated and the link(s) are enabled again). Another drawback is that devices usually must have STP enabled in order to forward the BPDUs (spanning tree frames). For example if you have a cisco switch and dont wish it to participate in the spanning tree and just run "no spanning-tree" this will in fact drop all incoming BDPUs making the rest of the network not be able to spot the loop and hey presto - you now have an amplifying loop in your network...
3) As far as I understand "BPDU protection" means "if a BPDU (spanning tree frame that is) is seen arriving on this interface, put this interface into blocking state". This is handy in order to automatically shutdown evil clients from where you shouldnt see any BPDU arriving. Depending on how the rest of your network is connected this could of course put your network into some kind of halt.
4) If using static trunk then the resulting trunk will be the "interface" used to participate in the spanning tree/used for loopdetect. If dynamic trunk is being used (such as LACP) then each physical interface will be an interface until the trunk has formed and then only the resulting interface will be used for the STP / loopdetect.
Some background:
Spanning-tree (if we ignore modifications such as RSTP and MSTP) will calculate a tree out of the participating devices and then figure out the optimal way to "disable" interfaces in order to avoid a loop. This is done by taking linkspeed into consideration (link cost) etc. That is with STP an interface has 5 possible states: blocking, listening, learning, forwarding and disabled.
The drawback with STP is that each time something changes in your L2-network for the links and devices who participate in the STP the full tree must be recalculated (convergence time so it takes about 35 seconds for a link to become active). This means this is a great "feature" to hog the system cpu in your network devices (switches and routers who are part of the STP). If you also get a loop who for some reason isnt detected properly then the situation can get even worse (then the looping link will drop frames which if unlucky will drop the BPDUs which then will start to recalculate the tree back and forth eating up all system cpu).
Also due to how STP works if its badly configured an evil client can become "root bridge" in your network so instead of having your 10G links as backbone this 10Mbit client will become backbone instead (which of course will make the network feel sluggish).
Another drawback with STP is as I explained regarding how different devices interpret "no spanning-tree". In cisco-world this means that ALL BPDUs will get dropped so the loop will continue undetected. Compared to with HP E-series where "no spanning-tree" means forward any BPDUs but dont participate yourself in the tree-calculation.
So one can say that STP is a protocol to exchange information of how a network is interconnected in order to calculate best links to keep up (and the others to be put in blocking state).
The difference to loopdetect is that loopdetect is a per device feature. Loopdetect doesnt exchange any information and doesnt care about loop frames from other devices. It only monitors and waits for loop frames to show up that was sent by the device itself.
This way there is no system cpu hogging going on because some far link (in your L2-network) is flapping.
Loopdetect will just send out a broadcast (I think it was) which contains the device mac-address. If this frame is seen on another interface then this other interface will get disabled (didnt read up on if it will become permanently disabled or if it will recover itself later by continue to listen for the loop frames to arrive and once they stop it will reenable the interface causing the loop.
So in short, loopdetect is a great replacement for STP but its not as "smart" as STP. A good recommendation is to keep your L2-networks as small as possible and by that virtually make it unneccessary to run STP. However using STP on infrastructure links can still be a good idea as a safety measure (given that you configure it correctly regarding root bridges, timers etc).
If using STP dont forget to secure it, SEC (Secure Enduser Connection) is a great set of documents who describes best practices to apply in order to secure your network: https://secureenduserconnection.se/wp-content/uploads/2010/06/SEC-Secure-End-user-Connection-2015-08-26.pdf