Should be fixed in r5757.

After the fix I start to wonder if this was actually caused by OpenMPT at all or if it's a bug in LAME ACM... now there is some additional silence at the start but the click is still missing, compared to other encoders (see attached file).

r5757 did not actually fix (or even change) anything at all. Looks like LAME ACM does not even set nCodecDelay. I (we?) probably got confused with the test outputs yesterday.
Investigating further.

Ok, I rendered the testcase using libmp3lame VBR (i.e. with LAME header), libmp3lame CBR (without LAME header), LAME ACM CBR and OpenMPT native WAVE output.
All renderings are 44.1kHz, stereo, 128kbps.
The 3 mp3s, when decoded using lame commandline utility (probably the best tool to get delays right, as LAME obviously knows about this stuff in order to be able to implement proper delay compensation with the LAME header), the VBR mp3 and the WAV properly align sample exact. The libmp3lame and LAME ACM version also align to each other, however, there is an additional ~13ms (did not take an exact measurement here) of silence/delay at the beginning.
Audio data is complete in all cases. I cannot see any missing initial kick.
LAME reports the skipped delay while decoding: It reports 529 samples for libmp3lame CBR as well as for LAME ACM. libmp3lame VBR (i.e. with header) reports 1105 samples delay skip.
The difference is (1105-529)=576 samples (exactly half an mp3 frame and also the specified encoder delay for LAME, roughly 13ms). LAME documents the encoder delay for the FhG encoder as 1160 samples, thus encoder delay differs from encoder to encoder in practice. There is no way for a decoder to know the encoder delay unless specified in some external way (i.e. LAME header).
Note: There are other decoders that do not even compensate for their own decoder delay (i.e. they add an additional amount of silence). Libav is such a decoder.
As of now, I cannot see any bug in OpenMPT or even LAME ACM here.

Versions tested:
libmp3lame 3.99.5 (32bit, VS2008)
LAME ACM 3.99.5 (32bit, VS2008)
lame command line (for decoding) 3.99.5 (64bit, GCC, Debian 8)
avconv version 11.4-6:11.4-1~deb8u1, Copyright (c) 2000-2014 the Libav developers

I seem to have found the key to this issue: At least with the ACM codec, there seems to be a difference in the exported result depending on whether ID3 tags are embedded or not.

Fixed in r5763