Machine code is a bizarre choice for a productive language. It is probably no better or worse a choice than any other high level language if the programmer is proficient with it. However to get the most out if it, you also need to have an intimate knowledge of your hardware. Just on portability, you can end up with machine specific restrictions confounding even the simplest machine code routines 'ported' to another system with the same processor even! (The entire range of Acorn machines using the 6502 variants are a prime example). There is also the demand that an employer may place on your requirement to make the code supportable - not exclusively by you, but your workmates who maybe grew up using FORTRAN, and then what are they going to do when they see your code interspersed with mnemonics like SWINE? Not like you for sure! My favourite comment in code - 'It was hard to write, it should be hard to read', and then no further comments, second favourite comment 'bloody 68000' in assembler code for an ARM processor, (converted sound tracker player). A reasonable high level language and a development environment will improve your productivity, maintainabilty (not a real word?) and code portability immensely - even the IDEs available for machine language that I've used have had a 'pseudo' high level language to remove a total dependance on raw mnemonic coding. I agree that some knowledge of the instruction set for your target processor can help in code 'optimising' after compiling (some compilers can have different ideas about what is required by the programmer, speed, compactness or 'just compile'), but it's the 21st century and compilers are generally very good at producing 'final' code. Then there is the argument for Java and virtual machines. Write your code once, run on ANY device in it's virtual machine without changing anything. (Thank you Microsoft for messing this ideal up). Take the 'Hello World' example and show me the SAME MACHINE CODE that will work on a PC, iPad and Commodore 64. (There are websites devoted to 'Hello world' and so far I have not seen one example of machine code that will do this, yet).
I love 6502 and ARM 'machine code', love being able to show the guys I work with my latest clip of 6502 or plugging away at ARM code to while away a dull afternoon, but it is no way going to impress the boss when he wants some script that can be started at the click of a button to fetch reams of records and flick out the overdue guff in a half an hour deadline - read Visual Basic here, uggg. I applaud anybody who takes code down to the metal, but today you only get a higher Nerd Factor rating for using machine code, kind of like self modifying code or using 200 GOTOs in a 500 line basic program because you don't want somebody to find the LET LIVES=3 in your latest game. Then again, there is the part in the film Independence Day, where, based only on a decaying radio signal the entire invading alien armada's operating system and underlying processor architecture is deduced and defeated with a bit of machine code produced on an apple powerbook, so we know it is the most powerful language in this galaxy, perhaps more people should be using it ;o)
Back to the server, for it's vintage, if it is not a SASI drive (the fore runner to SCSI) it will be some generic MFM probably run from a Seagate (formerly Shugart) controller any way. SASI would be a problem, but for the others, replacement drives are abundant, and devices that simulate the original 'disk hardware' are available. The biggest problem will be getting a suitable OS for the zilog beast if it is a Z8000. Not sure that 16/32bit CP/M was overly popular! (I've got an 8MB MFM drive, kept it because of it's physical size to show how far PC HDD tech has come, but for the right 'hundreds of dollars price' ;o) I'll part with it so somebody can get their archaic server to run, no guarantees that the disk still works mind you).
If the computer is a runner, and the seller really does not know how to connect up a terminal to check, pretty much any 8bit machine you can name will do a very good impression of a terminal easily. (And the first time I used an apple Macintosh was as a terminal, so that would be my choice - despite the Appletalk networking!) I don't know if you've tried it, but there's even 'term.exe' (hyperterm for you 32bit people) in windows for this, or at least there was in the old versions of windows that had windows.