Under normal conditions only the root ID and bridge priority of the VPC primary will be sent via VPC downstream links. Within VPC links only the operational primary transmits or processes BPDU's (nb - the secondary forwards rather than proxies). In the case of non-VPC links the actual ID's and priorities will be sent, thus allowing STP to continue to function as expected.
Best practice is that the lower (better) root priority should be on the VPC primary. If it isn't the case and the seondary has a better priority then downstream VPC connections will still receive the ID and priority of the VPC primary - even though it's the worse of the two.
If the VPC primary fails (loss of peer link + peer keepalive) then the VPC operational role shifts as the VPC secondary assumes the role of primary. In this instance you are correct that a new root bridge has appeared and STP needs to run throughout the topology - with attendant interruption of service. This is where the peer-switch feature comes in...
When enabled the peer-switch command actually causes the two VPC paired switches to create a third (common) virtual root ID that should always have the lowest priority in the topology. This means that both switches are going to send BPDU's with the virtual ID as the root of the topology and their respective physical bridge ID's as the candidate for designated forwarder.
So - Any downstream non-VPC switch will see a common root ID and two potential candidates for designated forwarder with distinct ID's but identical priorities (nb - strong suggestion that VLAN STP priorities be equal on VPC peers) and will pick accordingly (..generally choosing the lower bridge ID).
For VPC downstream switches the BPDU created by the VPC primary will just see a neighbor of the new virtual root address. In the event of a failure the secondary will maintain the identical advertisement - same ID, same priority... so zero STP convergence required.
Spanning tree itself doesn't have anything like what you are asking. As the network designer, you assign the priorities to ensure that the correct bridge becomes the root bridge. How you select which bridge should be the root depends on how you want the traffic to flow, and that is up to you as the network designer.
If the majority of your traffic is kept within the LAN, then, yes, you should pick the bridge closest to the center of the LAN. If most of your traffic exits the LAN, then you should pick the bridge where your router is connected.
You design the LAN topology to fit how your LAN will be used.
Per your comments:
The LAN diagram to which you linked is something that cannot be reasonably supported. Yes, networks sometimes grow in an unreasonable manner, but that network would need to be redesigned to introduce layer-3. We no longer live in the layer-2 world that existed when STP was developed, where it was, "switch where you can, route where you must." We live in a layer-3 world, and almost nothing requires you to have a large layer-2 LAN.
You can drive just about any protocol to its limits, but that should be avoided. Recent best practices really limit the usefulness of STP to be a failsafe because depending on STP can make your network more fragile, and experiencing an STP problem will render a LAN useless. With a LAN, such as you depict in the drawing, a business can lose millions of dollars per hour/minute/second due to STP problems, which are notoriously hard to correct. No sane business will allow such a LAN.
STP, itself, has some default values for things like diameter, and you change those at your own peril.
Correction:
You question claims, a few times, that the root bridge is selected by bridge ID and MAC address. It is selected only by the bridge ID, of which the MAC address is part. The bridge ID is the bridge priority plus the MAC address, and the MAC address is not considered separately when selecting the root bridge. The most significant part of the bridge ID is the priority, and you need to configure the priority if you want to determine (and you should want to determine) which bridge becomes the root bridge. The MAC address is only significant if there are identical priorities.
Best Answer
according to comments in the question, the actual topology is two bridges:
B1 (root) --- B2.
According to the specification (IEEE Std 802.1w-2001, sec 17.7)
That means that periodic hellos are only transmitted on designated ports, not all ports. In particular, hellos are not transmitted on root ports.
The idea is somewhat following. Both STP and RSTP track the liveliness of the "parent" node in the spanning tree (which is the root port). This is important, because if parent node fails, STP/RSTP needs to take actions to repair the tree.
Tracking liveliness of child nodes (bridges attached to designated ports) are not really important. Parent node is not doing anything if the child fails. Note, that the port is not necessary attached to a point-to-point link, and end-systems may still be reachable if the child fails. So RSTP can't turn port off and/or stop sending payload frames there.
So, in RSTP (actually similar to STP) liveliness messages are only sent from parents to children along spanning tree. In STP root sends messages and other bridges relay messages. This is because STP cannot do anything to repair topology without participation of the root node, i.e., until the topology converges with new tree build from root again. With RSTP, bridges can repair topology "more locally" - e.g., switch to alternative ports. Thus each bridge sends the liveliness individually to its "children".