Well, the Boneh-Lynn-Shacham "BLS" signature scheme is currently in the process of being standardized through an Internet Draft named "draft-irtf-cfrg-bls-signature-00" (a working document of the Internet Engineering Task Force "IETF"), which you can track here. It appears Algorand might be behind this process, along with Dan Boneh's own support.
As stated in there:
There are two variants of the scheme:
(minimizing signature size) Put signatures in G1 and public keys
in G2, where G1/E1 has the more compact representation. For
instance, when instantiated with the pairing-friendly curve
BLS12-381, this yields signature size of 48 bytes, whereas the
ECDSA signature over curve25519 has a signature size of 64 byes.
(minimizing public key size) Put public keys in G1 and signatures
in G2. This latter case comes up when we do signature
aggregation, where most of the communication costs come from
public keys. This is particularly relevant in applications such
as blockchains and compressing certificate chains, where the goal
is to minimize the total size of multiple public keys and
While they do not (yet) specify explicit parameters that are to be used, they do refer to the Internet Draft "Pairing Friendly Curves", which in turn has multiple recommendations depending on the level of security you want to reach.
Regarding the above quote, it notably lists BLS12-381 in the recommendation to have 128 bits of security.
Also, when compared with ECDSA, they mention that (emphasize mine):
The following comparison assumes BLS signatures with curve BLS12-381,
targeting 128 bits security.
In terms of sizes, ECDSA uses 32 bytes for public keys and 64 bytes
for signatures; while BLS uses 96 bytes for public keys, and 48 bytes
for signatures. Alternatively, BLS can also be instantiated with 48
bytes of public keys and 96 bytes of signatures. BLS also allows for
signature compression. In other words, a single signature is
sufficient to anthenticate multiple messages and public keys.
So it appears that the current "standard" is to have ~384 bits of signature to reach 128 bits of security, which means having $3b$ bits signatures for $b$ bits of security. (BN curves having "lost" favors, as Bristol said already and their current 128 bits contender being BN462.)
Also, notice this is a working document, and as such is not complete. For instance it is missing things that are yet to be added:
TBA: additional discussion on this, e.g. [Ristenpart-Yilek 06], and alternative mechanisms for securing aggregation against rogue key attacks, e.g. [Boneh-Drijvers-Neven 18]; there, pre-processing public keys would speed up verification.
And the rogue key attack is typically something important to defend against in the case where we want to have aggregate signatures, which is one of the nice features of BLS.
Notice that in pairing based crypto we had to move significantly our security estimates within the last 3 years most notably because of the advances in the FFDLP (see [KB16]), with your latest reference [BD 2019], being the current state of the art regarding security estimates and recommendations.
So it might still take a while until the above-mentioned IETF draft is finished and becomes an actual "standard", but this is in process.