First, anyone taking the time to read and help me with this issue, THANK YOU!
WARNING: I am a rookie with the BGP protocol albeit I have been working with RouterOS for over 15 years.

Here is my live scenario, I we have four routers and 20+ road warriors (RW). Two of the routers will be configured to handle connection activity from RWs.

This is the issue I see in our tested configuration: The Routers themselves can ping any resource on any LAN across the routes, the RWs can get any resource on any of the LANs. The desktops in each of the LANs cannot access any of the other LANs across the routes. iBGP advertising is up and working, otherwise the RWs would have the same issue. Somewhere I have taken a misstep in my configuration or I have a misunderstand of the BGP configuration.

In my lab I have 3 Mikrotik routers set up with WireGuard, as follows:

These routers are going to be geographically located in different parts of the county and are the gateways to the offices they will be homed in.
The router at Headquarters (HQ) in Seattle, has a dedicated WireGuard (WG) interface for each of the other routers and a dedicated interface to the road warriors (RW).
An example of what those WG interface settings have at the HQ Router:
Name Address Port
wgToLA 172.17.5.1/30 13281
wgToHOU 172.17.5.5/30 13282
wgToMIA 172.17.5.9/30 13283 (this is the other router set up with RW access)
wgToRW 172.17.5.128/25 13284 (for road warriors only)

There is obviously a peer for each of those interfaces on the HQ router. There are only four settings needed for the peers on the HQ Router, as follows:
Public Key = <from the other endpoint>
Allowed Address = 0.0.0.0/0
Preshared key = <matching key here>
Persistent Keepalive = 00:00:25

Each of the other routers has a single WG interface with a peer pointing back to HQ. Except for wgToMIA which also has a RW Interface.
For example, the LA interface would have this:
Name Address Port
wgToHQ 172.17.5.2/30 14281

And it's peer would have the following:
Public Key = <from the other endpoint>
Endpoint = HQ.myexample.com (our endpoints are static and mapped)
Endpoint Port: 13281
Allowed Address = 0.0.0.0/0
Preshared key = <matching key here>
Persistent Keepalive = 00:00:25

------------- iBGP --------------
The HQ router is set up as the Hub in this iBGP configuration, such that it has a session to each of the other routers.
This is typical of the HQ BGP configuration.
Name = RouteToLA
AS = 100
Router ID = 172.17.5.1
Remote Address = 172.17.5.2/32
Remote AS = 100
Local Address = 172.17.5.1
Local Role = ibgp rr
Connect = yes
Listen = yes
Routing Table = main
Output Redistribute = bgp
NextHop Choice = force self
Output Network = BGP-Out (list containing HQ LAN range, example 192.168.0.0/23)

The iBGP clients like the LA router has these BGP settings:
Name = RouteToHQ
AS = 100
Router ID = 172.17.5.2
Remote Address = 172.17.5.1/32
Remote AS = 100
Local Address = 172.17.5.2
Local Role = ibgp rr client
Connect = yes
Listen = yes
Routing Table = main
Output Network = BGP-Out (list containing LA LAN range, example 192.168.2.0/24)

Session status shows Established, Uptime, TX and RX.
When I open a terminal and run: "routing bgp advertisement print" I see the correct dst addresses for each of the peers.

------------ Road Warrior Config ------------------------
[Interface]
PrivateKey = <from this interface>
ListenPort = 13821
Address = 172.17.5.43/32
DNS = 192.168.0.1, 192.168.0.2

[Peer]
PublicKey = <from router endpoint>
PresharedKey = <from router endpoint>
AllowedIPs = 172.17.5.0/24, 192.168.0.0/20
Endpoint = hq.ebcorp.us:50821

As stated above our RWs can see all the LANs however the desktop clients on each of the LANs cannot access the other LANs.
How do I get my desktops to see each other across the routers?

Output route table + configs (with sensitive info hidden) and then we might be able to give an idea.

Even though a router can see other LANs, the important information is the source IP.
A general trick is to traceroute from a desktop to another desktop to see what the last responding hop is.

Then look at how it routes, and how the route back would look (based on the src ip you are connecting from)

Do you have NAT rules affecting it?
Do you have mange rules affecting it?
Do you have filter rules affecting it?

Unfortunately whilst the info you've given gives a brief topology idea it does not let anyone get a true idea of what the issue might be.