Option A (daisy-chaining) can work just fine.
It's not really the best way to go about things, and Option B ("star" designs, with each device connecting back to a common core) should be preferred when possible.
I run the network for a small campus, and in our network I try to limit to one additional link beyond the initial connection back to the core device. So if we think about these as switches instead of Routers/APs (since that's how we're using them here), CoreSwitch might link to SwitchA, which links to SwitchB, but I wouldn't want SwitchB to then link to SwitchC. I'd find a way to have either B or C also go directly back to the core.
I do have a two or three cases when this still does happen, and again: it does work. But don't have this be the default way you do things, or the first tactic you look at when connecting new devices. In fact, I'm in the middle of a project right now to get one "SwitchB" device connected directly to our core instead of another "SwitchA" (via fiber, yay!), so the downstream "SwitchC", which was added recently to support an Esports room, will no longer have so many hops.
This is especially true if you have any wireless trunk links. Mesh networks can work okay, but it's putting a lot of extra traffic on the least-reliable, slowest, and most-congested medium available to you. I see mesh as a backup option only, for when the existing wired link is broken.
On more advanced networks, you go even further and could link the Core to both A and B, and one of those might link to a switch C, which in turn might link back to one of others, creating a loop. And if we stopped there you'd have a broken network, but then you take advantage of Spanning Tree Protocol and now you have redundancy, where the network can use the surplus line as a sort of hot spare, so if one of the lines is damaged the extra link can automatically step up to provide service.