Learn real C, then come back to HuC.
Yep, then running screaming away from it. 
It is easy to get something up and running, but if you do want to port anything or do something slightly approaching ANSI standard it's a big pain in the bum. One of the reasons I never got around to finishing the FAT filesystem driver for the Everdrive is the lack of struct support, so doing anything with the FAT table was a pain, calculating offset after offset for table entries... argh!
That and the lack of 'long' support. Yes, I know it is slow on a 8bit cpu, but my word, when you don't have 32bit integer support these days you do feel it!
Well, it does have a lot more ANSI stuff in Uli's new HuC, especially "struct"s.
That should make it easier for newcomers to pick up and use (except that there's so little documentation on it).
And as Bonknuts pointed out, there are some 32-bit math functions down deep inside that you can call from assembly language.
But ... it's still *far* from compatible with true ANSI C code, and so you'd end up doing a lot of assembly work.
HuC is really a C-lite language designed for making games.
To answer the original question, what would you think about using the CC65 compiler/assembler suite, as an alternative to 100% hand coded ASM?
I never coded anything targeting the PCE, but I'm currently using it to learn the Apple II. Of course the performance of the compiled C code is bad, but I find it sufficient in the non-critical loops.
And it's easier to experiment in C than in ASM 
If you look, you'll find threads here about CC65/CA65.
There are so many things that I like about it, especially all the work that has gone into optimizing it, and into making it fully ANSI-compatible.
But, the price that has been paid in terms of code-generation complexity, and performance is a little bit too high for my comfort.
There's also little support in their libraries and system for the PCE's memory model and CD usage ... support of the PCE is at an early "work-in-progress" stage.
CA65 itself (especially when used with CC65) currently has some problems when it comes to zero-page variables that I've been trying to sort out with the guys there.
The root-problem itself is buried deep within the core of CA65, and I'm not sure when it will be fixed.
If you want to use C
on the PC Engine, then I'd have to currently recommend HuC over CC65, especially after the work that Uli did on improving the ANSI-compatibility.
Unfortunately, the documentation on HuC, and how to get the best use out of it, is sadly lacking.
I'm a programmer ... I'd rather have a root-canal than write documentation, and this is one stand-out area where I've got to tip my hat to the CC65 guys!
<EDIT>
I never coded anything targeting the PCE, but I'm currently using it to learn the Apple II.
BTW ... I ran across your blog a few weeks ago, and enjoyed reading it!
If you choose to try writing something for the PCE, then you'll find it to be a much more powerful machine than the Apple II, and the Hu6280 processor really adds some nice intructions to the 6502 architecture that make it so much more pleasant to work with.
That's another problem that I have with CC65 ... it takes very little advantage of the 65C02 improvements, and has no optimization at all for the Hu6280 improvements.
