I think it's important to note that the provided saPAKE Double BS-SPEKE does not come with a security proof. A proof of a similar protocol is not hard if you believe in the compiler provided in the JKX18 paper[1] and you believe that B-SPEKE is a UC-secure aPAKE but it's important to note that the JKX compiler is not proven secure against the updated functionality from their revisions. Further, I don't believe that B-SPEKE has a security proof in any model let alone the UC model.
But I can say for certain that the currently described protocol is not a secure saPAKE as it doesn't prevent an adversary from impersonating a client after stealing the server's password file.
The adversary learns (B, salt, P, C, s, b, regMAC) and needs to produce (a * P, H(idC, idS, A, B, a * B, c * B, s * A))
a is uniformly sampled, so the adversary knows a * P, A, B, a * B, and s * A. We're missing c * B, but this is just b * C which we know. So the adversary can produce all messages required and arrive at the server's key.
This may not be a security guarantee that you need for your use case, but I cannot recommend Double BS-SPEKE as an saPAKE (or even an aPAKE) until we see a formalized analysis of its guarantees.
[1] OPAQUE: An Asymmetric PAKE Protocol Secure Against Pre-Computation Attacks https://eprint.iacr.org/2018/163
--- EDIT ---
I just came across the original talk https://www.youtube.com/watch?v=gopo2FI9epw using the term "doubly augmented" and I'll update this post soon.
I'm still not sure what "doubly augmented" means, but the talk seems to conflate the security properties of OPAQUE and double BS-SPEKE as well as listing doubly augmented as a subset of augmented PAKEs.