Using HMAC as a nonce with AES-CTR encrypt-and-MAC Suppose I use the following encrypt-and-MAC construction:

$E(k_1, k_2, n, m) = E_\text{AES256-CTR}(k_1, n, m) \| \text{HMAC-SHA256}(k_2, m)$, where:
$k_1$ and $k_2$ are 256-bit keys
$n$ is a nonce
$m$ is an arbitrary-length message.

What security losses occur if I use the MAC as the nonce? (i.e. $n = \text{HMAC-SHA256}(k_2, m)$, but truncated to the appropriate length)  Are there any other disadvantages to this scheme compared with typical authenticated encryption, e.g. AES-GCM?
Clearly, this scheme is distinguishable under chosen plaintext attack, since the same plaintexts always encrypt to the same ciphertexts.  This is acceptable in my application, but I'm interested to know if there are other problems.
What you're describing is pretty similar to the SIV block cipher mode. It also uses a deterministic function of the message to derive the nonce for CTR encryption. Under some pretty widely accepted assumptions about HMAC-SHA256 this is a perfectly fine way of achieving deterministic authenticated encryption. It doesn't meet IND-CPA (as you pointed out) but if this is acceptable for your application, you should be fine. 

Disadvantages are mostly in terms of efficiency. The mode you propose requires two passes of the plaintext to generate a ciphertext, but GCM only requires one. A mode like OCB also only requires one pass for authenticated encryption, but is parallelizable as well. The impact of this is, again, dependent on your application.