My question, due to almost total ignorance about computer networking: do the packets that are on the network that are not being sent to or received by the ip address of a device still contribute to the device's total bit rate?
It's not the device's total bit rate but the Ethernet link's – 10 Mbps is one of the standard data rates for an Ethernet connection (10BASE-T) – so any packet that crosses the Ethernet cable will contribute to the "total bit rate", and it physically cannot send more than 10 Mbps (in one direction) when running in this mode.
It's the sender (e.g. Ethernet switch) that makes the decision whether to send something or not; the device cannot refuse to receive a packet once it hits the wire, even if that packet doesn't have the right address. Either it has to receive and discard the whole packet (meaning that all such misdirected packets contribute), or "the network" has to avoid forwarding in towards the device the first place.
On modern networks it's the Ethernet switches that would be responsible for filtering most of the unrelated traffic, based on its destination MAC address. They learn which MAC address is behind which switch-port, and in normal situations only packets sent to your MAC (plus broadcast packets) should be output through the Ethernet switch-port that you are connected to.
It means that even with Wireshark in promisc mode, you shouldn't be seeing packets meant for other devices' MAC addresses – if your test Wireshark laptop is receiving a ~38 Mbps flood of packets not meant for it, then something wrong is going on. (Though I can't really speak for industrial networks, but you should not be seeing that on any ordinary Ethernet LAN.)
Sometimes this filtering doesn't quite work; it relies on the switches learning the MAC-to-port mapping based on packets that each device sends. If a device stays completely quiet then switches won't have the opportunity to learn where its MAC address is, so every packet meant for that device will be broadcast through all ports instead. If the network has 100 devices receiving commands but never speaking, it's certainly possible that those packets will be flooded. On the other hand, if you're seeing bidirectional communication, that's definitely not right.
The second stage of filtering, within the Ethernet controller, is what "promisc mode" in Wireshark refers to (re music2myear's comments) – the controller would discard received packets if they don't have the right MAC address (and Wireshark temporarily turns this off to do its job) – before passing them "up" for further processing. This used to be a necessity on shared-medium networks. But on switched networks, promisc mode cannot "pull" packets that the switch isn't supposed to be sending you, so I doubt that it would be the problem.
(Checking for IP address is another stage after that; only after switches forward the packet towards your port, and the controller accepts it as having the correct destination MAC, then the destination IP address comes into play.)
