~dtBy

What is your confidence that these identities are controlled by the same person

High confidence. I would consider them basically identical in terms of who I expect to be in control of these keys and signing messages in the respective formats.
However, the following things could be considered:

• Sharing a key between systems, unless using an external key managing thing, exposes each system to the other, i.e. increases the trusted computing base of each system. Your SSB code now has access to your Bamboo private key, and vice versa, since the key is the same. But this might not matter in practice, e.g. on a desktop computer where applications are not sandboxed from eachother and the filesystem.
• To publish to an SSB feed you need to know the latest message. Probably the same for Bamboo? The latest message is probably considered public. But maybe there could be scenarios where the key is compromised but the latest message is not known?
• If your key is compromised by an attacker, maybe they wouldn't want to attract attention by publishing to your feed, but instead may use the key elsewhere, e.g. authenticating with secret-handshake, or asking someone to manually verify their signed message. From this perspective, maybe it would be best to explicitly express relationships between feeds in public messages within the respective feeds.

How does this relate (if at all) to ~cel's DID stuff?

For DIDs in general, I think it is analogous to different DIDs (maybe of different DID methods) sharing verification material - i.e. the same public key appearing in different DIDs. In the DID+VC model, there is no explicit inherent association between DIDs that use the same public key in their verification method. did:key, did:pkh, did:nacl, and probably others, can all represent a Ed25519 public key as a DID, and resolve the DID to a DID document by deterministically generating the DID document from the public key. But none of these DID method specifications make explicit this correspondance. (Although an implementation could do so anyway, but this could not be expected to be interoperable). did:onion, did:ssb also use identifiers based on a Ed25519 public key, but with a mutable DID document, and these also make no association with other DID methods based on the public key.
Similarly, a Secp256k1 public key can be used to derive a did:ethr (mutable), or did:key (static). And there are also DID methods based on a hash of a public key (did:pkh, did:tz, did:ethr usually); for these an association could generally only be made in one direction (from a DID based on the unhashed public key, to a DID based on a hash of that public key).
The formal way to make the association would be using equivalentId & canonicalId DID resolution metadata properties. Or, an association could be made in the DID document using controller or alsoKnownAs properties. (alsoKnownAs is a weaker association; controller is a significant grant). Or maybe by issuing a verifiable credential to the other DID to express the relationship (but this might be application-specific, not part of DID core).
So basically, while the key material may be the same for some DIDs, software systems are probably still going to treat those DIDs as separate, because the expected way for DID methods / DID resolvers to indicate identity/equivalance between DIDs is via the above mentioned properties and metadata, not by introspecting and comparing the verification material, and DID method specifications are tending not to specify these kind of equivalences across DID methods. DID methods do however often reuse formats for the public keys in the DID methods - called verification methods, e.g. JSON Web Key 2020, Ed25519VerificationKey2020, EcdsaSecp256k1VerificationKey2019, and others in listed in DID Specification Registries - Verification method types.