Of course it is. B9S 1.3 didn't even change anything major like 1.2 did. They just mainly removed padding so it can fit on more flash cards for NTRBoot. And they updated to the latest FATFS, but, you're really not going to notice better file system handling on something that runs for a fraction of a second at boot. So, updating to 1.3 is completely optional in the first place. But this will work just fine either way.
Even better, it's GM9 compatible. So, no reason to keep using B9S for your firm at all. Well, other than the fact that it gets updated less, but if you stick to stable GM9 releases, you're not likely to wear your NAND out anytime soon. The extra features are more than worth it, IMHO.
The only thing it's not compatible with is Decrypt9. You'll need to run that through another chainloader. You could hotkey CTRBootManager9, and make D9 the only menu item with a 0 delay. If you're already using CBM9 for an "extra payloads" menu of lesser used apps, you could hex edit a copy of it in .bin format and change the location of the configuration file then re-compile it with firmtool (you can use the default conversion example in the readme for firmtool, just add "-i" switch at the end). Or, if space is no concern, you could compile a GM9 SSR using a one line "autorun.gm9" file that simply says, for example, "boot 0:/b9s/payloads/Decrypt9WIP.firm" (note that this is based on where I place my copy of D9, you may place it somewhere else). Even that option will still take less than half of a megabyte, but that CBM9 can do it in about 1/3 the space is something to be mindful of if working on a swap card or cart-only install method.
My InScripted AIO (that iso site, CFW Discussion section, if you want to check it out, it has the D9 work-around built in, includes "Sighax Updater" for easily upgrading to GM9, and includes scripts to setup your hotkeys) has been using this for the default chainloader from day one, because it simply has the best compatibility. BootCTR9 worked flawlessly with Cakes before 202 came out, for example (200 crashed under Luma). And it's still the only thing that can boot a converted Gateway or Puma33DS payload. And you can laugh at my use of a venerable Luma fork all you want, but it's one of the best for running a 9.2 EmuNAND if you keep one of those around for launching homebrew that doesn't work with Rosalina (though 11.6 does actually work with Puma). It seems to crash less with CTRHexenII and Spectre3DS than my modified Luma Legacy using the "legacy" folder.
