As Thorbjørn Ravn Andersen already put it nicely:
What would you need it for?
There is almost no practical (*1) need to obtain the PC address at runtime (*2) - it's a value to be obtained during assembly time, provided by Assembler and/or Linker. A simple
HERE: LEA AX,HERE ;(*3)
will make sure the Assembler and/or Linker puts the actual instruction's address into a register (AX in this case).
Now, if you really want to do the trick, than best do it like it would work with any CPU: Jump one instruction ahead by using a subroutine call and then pop the return address.
CALL NEAR PTR NEXT ; Make sure it's not a far call *4
NEXT: POP AX
Except, there's a major caveat:
Above is trouble-free only in clean 16-bit code. Different addressing modes may require use of 32-bit registers and more.
Going for tricks like this is a sure way to introduce incompatibilities. It's the old story of programming what you want to do, not how to do it. Letting your tools, compiler/assembler/linker, do the 'dirty' work ensures it gets performed the best possible way.
As said, there is no real use for IP being one of the accessible registers; many quite successful architectures (/360, 68k, 8080, 6500, etc) do not have a directly accessible PC. They have at most a PC relative addressing (68k).
The PC is never a 'normal' register but is tied to the basic mechanics of a processor. In fact, it brings a lot of advantages (*4) having it completely separated and not readable, as on 8086 and others. It offers the most simple way to separate operational housekeeping (like (pre-) fetching) from logical operation. The only use case for storing it is in the case of a subroutine branch. This can be handled keeping a shadow copy of the next address to be executed.
Architectures that allow the use of a PC in addressing may need to hold a second shadow copy with the instruction's address, complicating it. Architectures that include the PC in the register set, or use one of their GP registers as PC, need to take care about several constraints. One visible sign is that some RISC implementations do need to use PC relative addressing with a constant offset from the actual location. But there is more.
Long story short: Better not care for the PC at all - beside jumping that is.
*1 - The "almost" case is dynamically created code - but even then it would be more appropriate to improve the generator.
*2 - And no, the standard use of
BALR Rx,0 by /370 modules to get a local reference for jumps and constants is an oddity due to there being neither an absolute nor a PC relative addressing, nor the ability to load immediate word (address) values.
*3 - And yes, a
MOV could be used as well in nearly all (simple) cases. I still prefer the
LEA as it allows even more weird address generations :))
*4 - It still may run into trouble depending on addressing modes and memory model.
*5 - This is only an issue in CPUs with a certain level of asynchronous operation, like having prefetch or speculative operation.