First, I don't recall Cisco documenting what's the bandwidth value that will be used when not explicitly defined.
Often, I'll see people will assume what happens, but even if they can demonstrate their predicted results on a specific platform, can they guarantee it works the same on all platforms both now and future?
(NB: I believe I mentioned this in a reply to one of your other QoS posts, but Cisco changed QoS results, in some cases, between pre-HQF and post-HQF using exactly the same configuration! I.e. upgrade IOS, different QoS processing.)
So, I always highly recommend you explicitly define the bandwidth, when using it.
As to the class and queue relationship, it's not always one queue per policy class, even excluding child policies.
Traditionally, all policy priority classes share a single queue, but some later IOSs now provide an optional second queue, all shared by all policy classes using it.
Bandwidth classes, unless using FQ, each have their own queue.
If FQ is configured, it creates a set of hashed flow queues. Pre-HQF, each of those hashed flow queues were each handled just like a single bandwidth class queue. Their actual dequeuing priority was computed based on the flow's IPPrec and class bandwidth setting, also compution differed based on IOS. (I recall, there were two formulas, based on before or after a specific IOS version/release.)
FQ pre-HQF, was actually WFQ, but post-HQF, FQ.
FQ, for post-HQF, although there's multiple hashed flow queues, class dequeuing adheres to what a single, ordinary, bandwidth class queue would provide. Basically, in this class, FQ operates much as a child policy would. You might think of it as an implicit, specific, child policy.
In above, I mention hashed flow queues. Basically, FQ will allocate a fixed number of flow queues (some IOS versions allow additional configuration of those flow queues, traditionally, many did not) and actual flows are hashed to a specific flow queue - conceptionally, much like Etherchannel.
