Kevin also regularly tweets interesting stories about his experiences as a game developer, usually when making archival copies of the original disks! His account: https://twitter.com/KevEdwardsRetro
It was a really nice feature to do quick-and-dirty assembly to get rid of some inner loop that allowed you to combine the two languages (BASIC/ASM) in such a way that you didn't end up with a separate source file and build step and a whole pile of data statements (which is how other BASIC dialects did it).
But for any serious application you'd definitely want to use a real assembler, the code didn't look very nice in the BASIC assembly dialect and did not adhere to the 6502 assembly language standard (for obvious reasons, it was tightly integrated with the BASIC interpreter).
Which standards didn't it adhere to? Plenty of reasons not to use it for anything significant, but I've used numerous 6502 assemblers and the BBC BASIC syntax is/was pretty normal. Standard mnemonics, standard addressing mode syntax, & for hex, . as a mandatory label prefix, and \ for comments - if this exact combination is unique, the overall appearance is well within the range of what counts as normal for this category of tool.
(Being able to put multiple instructions on one line is unusual, but it's also pretty useful.)
That is a very good question and I'm really sorry that I won't be able to answer it. All that I remember is that I took a bunch of source files from older projects (mostly KIM-1) and tried to import them into BBC basic assembler and ended up having to do a bunch of changes (for instance the '&' sign for hex numbers, instead of $) to get it to accept them, as well as some missing directives. But it's too long ago to remember the details, and I don't have any systems from that time anymore (except for my very first Sharp pocket computer :) ).
That approach uses DEBUG to do the assembly, and then you generate a string in QBASIC containing the assembled bytes. BBC BASIC had the assembler built in, so you'd put the mnemonics in the program code and the interpreter would generate code for you.
One of the built-in variables dictated where the generated code would go, and there was a mechanism for doing 2-pass assembly to resolve forward references. Original manual section for this feature: https://archive.org/details/BBCUG/page/n439/mode/2up
The facility was a bit primitive, even by the standards of the time, chiefly because code and output and symbols all had to live in memory at once, so you'd inevitably need some form of multi-part setup. But you could (and many did) use it to actually write decent-sized programs, even if it probably was a bit annoying: https://www.bbcelite.com/about_site/about_this_project.html
You could go the other way and use a proper assembler with some macros and equates for the basic tokens to generate a valid basic file. They're all just bytes.