Compare: FromBank <-> ToBank (BankAPI, decentralized) vs. FromBank <-> SWIFT <-> ToBank (SWIFT, centralized)
(FromBank = Bank sending the message) (ToBank = Bank receiving the message)
That lumps a whole lot of complexity on FromBank, if the onus is on them to ensure ToBank correctly received the payload.
SWIFT takes care of all of this. You also have to guarantee to be connected to the SWIFT network for at least 7 hours per day to process your inbox, and new banks get silo'd in a test area for two months where they have to prove their systems are functioning properly within the SWIFT env before they're connected for real.
As long as FromBank gets its confirmation when it posts to SWIFT, job done. SWIFT takes care of ensuring it gets to ToBank.
With BankAPI, the response from the request comes directly from the beneficiary bank, meaning you know in real-time the message has been delivered. Compared with SWIFT, you only know SWIFT has received the message in real-time.
If the beneficiary bank can't be contacted for what ever reason, the sending bank (FromBank) simply keeps on trying until the beneficiary bank (ToBank) are back online again. The problem with DDoS is a valid concern, but given the banks Internet banking services are also accessed by the banks users via the Internet, they are already dependent on the Internet.
If you don't need real-time messaging and if cost nor complexity is a concern, then you probably won't find BankAPI interesting.