To make the encoding more compact while still having a large number of registers. A normal arithmetic instruction will have two 3-bit register fields, 1 3-bit effective address type field, and 3-bits that determine the size and direction (i.e. whether the effective address is the source or destination operand). Since an instruction word is 16-bits, this leaves 4-bits to select the operation type. This is a bit of a simplification as some instructions have more restrictions and move instructions are more expressive, but you get the idea.
Having a flat 16 register file would require two extra register bits in most instructions which would either halve the number of possible operations or require bits to be removed elsewhere. Since the operations required on pointers is typically much smaller than those required on non-pointer integers, this setup makes a certain amount of sense. The big downside is that as ajross points out, it complicates register allocation in a way that just about no other "mainstream" architecture does.
Other tradeoffs (larger instruction word, fewer addressing modes on "normal" instructions, requiring an extension word for more addressing modes, etc.) could have produced a cleaner architecture at the expense of code density. Code density was a big deal in the late 70's when the 68000 was designed due to the cost of memory.
EDIT: A flat 16 register file would actually quarter, not halve, the number of operation types since you lose 1-bit per register field.
Say you have a pointer to the start of an array and a pointer to a certain element and you want to turn that into an index. Not super common, but not a crazy special case either. I'm not sure why the other poster thought this was a limitation on the 68000 though as subtraction is one of the few arithmetic operations you can perform on address registers. Perhaps he/she confused the limitations of the AU (address unit) with limitations on address registers? The AU is used for calculating effective addresses and all it can do is add; however, normal add and sub instructions use the ALU even when working exclusively with address registers.
There are a bunch of other operations that you can't do on address registers (or at the very least, an address register can only be used for the effective address operand). This can be inconvenient if your code needs a bunch of registers, but not very many pointers. Not a huge deal otherwise.
Having a flat 16 register file would require two extra register bits in most instructions which would either halve the number of possible operations or require bits to be removed elsewhere. Since the operations required on pointers is typically much smaller than those required on non-pointer integers, this setup makes a certain amount of sense. The big downside is that as ajross points out, it complicates register allocation in a way that just about no other "mainstream" architecture does.
Other tradeoffs (larger instruction word, fewer addressing modes on "normal" instructions, requiring an extension word for more addressing modes, etc.) could have produced a cleaner architecture at the expense of code density. Code density was a big deal in the late 70's when the 68000 was designed due to the cost of memory.
EDIT: A flat 16 register file would actually quarter, not halve, the number of operation types since you lose 1-bit per register field.