Stephens Answer points out most details, I belive it's worth to mention that the 80186 is not incompatible with the IBM-PC's structure/hardware per se. The CPU core works for all details like a 286 in real mode, with the same additional instructions and exceptions, as there are:
- Array Check (BOUND)
- Integer Multiplication Immediate 8/16 (IMUL)
- Push Immediate 8/16
- Push/Pop All (PUSHA/POPA)
- Shift Instructions with Immediate Count (ROL/RCL/SHL/etc.)
- Multi Byte/Word Input (INSB/W)
- Multi Byte/Word Output (OUTB/W)
- Stack Frame Handling (ENTER/LEAVE)
- INT 5 Array Check
- INT 6 Unused Instruction
- INT 7 ESC Instruction (FPU)
So far software will run into the same incompatibilities as with an 286.
Further it's incompatible additional hardware aren't as much of an issue, depending on the design choosen.
As Stephen said, the included peripherals are superior to IBM's choice of 8 bit components. This is especially true for the DMA controller, able to transfer to any location at any length (up to 64 KiB).
While the address structure of the I/O block is complete different from the PC, it doesn't get in the way of any PC hardware as it it located at FF00h after reset. An area no PC-hardware (I know) occupies. Not even later one. It can be moved to any location in IO or memory address space.
The most obvious way to reach IBM-PC compatibility would adding everything exactly s the PC did. While this would eliminate many of the advantages of having integrated peripherals, but that sounds worse as it is, as most of a PC-I/O could be added as a single southbridge chip.
The only remaining incompatibility would be the Interrupt Controller (PIC), as it's located on a different address.
This is where the quite handy address decoder could be used. By connecting it's output to NMI and setting it to cover the I/O address range 0000h..03FFh, which is the range all I/O in the original PC was located, it would generate an NMI (*1) with each access (*2). Now an NMI handler can decode the offending instruction (*3) and translate it to the real hardware and back.
With 80186 systems running at least at 6 MHz or above, the translation layer's performance impact was tolerable. In fact, I do only remember one usage which could not be emulated, and that's active sound generation, that's were the CPU essentially handles the speaker in software. something already critical on genuine hardware.
The Olivetti Prodest PC1 of 1987 (!), based on a NEC V40 (a SoC much like an 80188, but with PC like timer/UART/PIO) did for use an NMI handler to emulate a PC compatible 8237 DMA controller while using the build in 20 bit DMA.
Long story short: It's quite possible to use an 80186 and its advantages while being mostly compatible.
The mentioned PC-D, being conceived as Unix workstation, did offer a different way. Here all memory and I/O was required to handle the READY signal, controlled by a watchdog timer provided by the 80186 as well. While this in theory could be used for emulation as well (I did so), the performance impact was rather heavy, as it only fired after about 1 millisecond. Eons in CPU time. The nice part was that the system ROM, much like MS-Windows, routed any NMI by default into the ROM based debugger. From there it was just a few commands until one could patch the offending software to run flawless :)
*1 - NMI is a strange fellow on the IBM-PC AT, anyway, as it could be masked. Jep, that's something one needs to read twice, as the very feature of an NMI is to be not maskable, so it can be used to report critical conditions (like memory error).
*2 - The same can be archived by simply selecting all I/O with top 6 bits zero, which needs a single TTL, leaving the PCS signals to other use.
*3 - While decoding an offending memory instruction, with just the address of the next instruction, as the NMI provides, is an quite complicated and rather error prone process, it's straight forward when it comes to I/O, as there are only 4 (well, 8 with INS/OUTS) opcodes to detect, and they have fixed formats.
To only possible ambiguity would be direct address (8 bit port number) instructions, but luckily That address range (0Exh) is unused on the PC. Similar the INS/OUTS do not collide either - well, they aren't to be expected with 8088 software at all.