Let's not spam the thread with our opinions of why C/C++ is so much better. We aren't like VB.net developers, after all ;-)
BlitzBasic did have access to normal AmigaOS libraries, including but not limited to Intuition. It is perfectly capable of creating OS legal applications. IMO, it always seemed a lot more OS friendly than say AMOS. I can only assume AmiBlitz retains this abiliy.
Also, as has been pointed out, an AMOS compatible language is also in development and I'm sure that it addresses the OS integration issue.
-edit-
Regarding the "weakness" issue, if you do want to use C, you might find compiling a painful experience on a basic 68000. The resulting code will probably be better in performance terms than something created in Blitz (but that's no means guarenteed on a basic 68000 either, after all blitz was designed for game production) but compiling it would be evil. Due to the amount of files that need to be pulled in and examined, a hard disk is an absolute must at the very least.
For C development I'd recommend at least an 020, 8MB of fast ram and a hard disk. That should be enough to run DICE or stormC 3 (as found on the DevCD 2.1), but you'd still find compiling a slow process.
-edit2-
I wonder if some of the C packages out there will allow the addition of assembly in C code. I know some do in the pc world
Most do. There are two ways you can go about doing it. First, you can define an entire function in assembler and have a C prototype for it. You have to make sure you don't trash the stack (at least the state it was before your call) or any non-volatile registers in your asm code. If you need to use register-exact argument passing you will almost certainly find different compilers use different constructs for defining them. It can be a pain.
The second way is "inline assembler". Mechanisms for that vary, but at least gcc allows the use of the asm() construct, which is pretty well documented.
I've actually used gcc's asm() in ANSI C++ mode to create functioning inline headers for amigaos library calls. It's a pain in the a*se, but it's better than having to create stub libraries for them.