The Hex/Octal thing basically depends on what types of computer one grew up with. While IBM documentation always used hex, DEC computers (such as the 12-bit PDP-8) and also HP machines were easier to work with in octal. Which is why the HP-65 and later machines supported decimal/octal conversion, of course.
As an example of why octal was sometimes more convenient, consider the Intel 8080. If you split the 8-bit opcode field into octal (from MSB to LSB), you wind up with a two-bit field, a three-bit field and a final three-bit field.
Now, if the two-bit field is 01, the remaining two three-bit fields represent the destination and source registers of a MOV, respectively, as shown in the following table:
A 7
B 0
C 1
D 2
E 3
H 4
L 5
M 6
So MOV A,D assembles into 0172. Knowing that the MVI (move immediate) opcode was 0x6, for example, it's obvious that 056 is a MVI L, instruction. And so on. There's tremendous orthogonality in the instruction set and opcodes that makes it very easy to assemble and disassemble using the Mark 1 human eye/brain combination - but it just doesn't work in hex.
I have here a couple of cardboard "slide rules": the "Tychon 8080 Octal Code Card" and the "Tychon 8080 Hex Code Card". As you slide the octal version, the patterns in the opcodes are obvious; as you slide the hex version, the patterns are much harder to see. The boundaries between hex nibbles just don't align with the opcode fields the processor actually works on, the way the octal digit fields do.
DEC and HP processors presumably had similar "octally-aligned" fields in their opcodes, while IBM didn't.
Of course, the complex instruction sets of modern microprocessors make it much more difficult to deal with instructions this way, and hardly anyone needs to identify opcodes by eye any more, so . . and in that case, you might just as well use hex.
Best,
--- Les Bell, CISSP
[http://www.lesbell.com.au]