Part of the situation you describe can be even worse. CS1/AF1x/IPPrec1 is, on many Cisco devices that provide QoS, is often defaulted into the same class as best-effort or even treated better (e.g. WFQ). The solution, either override default QoS for the marking and/or swap BE with CS1/IPPrec1.
For you concern about one set of traffic markings, which shares physical QoS class processing with other marked traffic, and the impact this can have against other traffic, is valid, even when not dealing with some kind of DoS. This, though, can sometimes be addressed by additional QoS features provided by the device. For instance, you might drop congestion sooner for one type of traffic over another that share the same queue. Or, perhaps you have an explicit policer for one kind of traffic.
The "multiplex" functions for MS NetBIOS/SMB is also a problem. I would suggest treating the traffic logically as best effort. On routers, that support FQ, placing NetBIOS/SMB into FQ goes far from one individual flow adversely impacting others. On most LANs switches, it's often difficult to deal properly with NetBIOS/SMB using QoS device features but generally bandwidth is usually both more plentiful and inexpensive.
PS:
Keep in mind, that QoS RFCs and SRNDs are really suggestions. They shouldn't be disregarded but the real purpose for QoS is to provide the necessary performance for your traffic in your environment. I.e. the goal of QoS is to make it work for you, not you work for QoS.