Disadvantage of high downsampling rates with CIC filters For a lock-in amplifier I am downsampling the demodulated baseband signal  prior to the final low pass filtering. This lock-in amplifier is implemented on an FPGA (myRIO of National Instruments).

Therefore I use CIC filters. I've reading a lot in Hogenauers paper and in "Understanding digial signal processing", by Richard Lyons. My downsampling rates are between 512 and 2048 (always powers of 2) as I want to decimate my input signal down to less than 100 Hz (e.g. 48kHz sampling will be decimated to 93Hz).

The gain of the CIC output is scaled to the CICs input by a simple bitshift afterwards.

Is there any disadvantage using even higher decimation rates?
CIC filters don't have very steep roll-off, or a very flat passband. That's the downside of using this very special class of filters.

Other than that, you should be fine. However, as with every filter design, you will have to design, and verify, yourself to ensure the filter matches your requirements.

However, CICs are very often used as runtime-adjustable filters; and that works pretty well if you have e.g. high-quality Nyquist-M (especially halfband) FIRs. An example of this is the Ettus USRP signal processing DDC: 

   // CIC decimator  24 bit I/O
   cic_strober cic_strober(.clock(clk),.reset(rst),.enable(ddc_enb),.rate(cic_decim_rate),
               .strobe_fast(1),.strobe_slow(strobe_cic) );

   cic_decim #(.bw(WIDTH))
     decim_i (.clock(clk),.reset(rst),.enable(ddc_enb),
          .rate(cic_decim_rate),.strobe_in(1'b1),.strobe_out(strobe_cic),
          .signal_in(i_cordic_clip),.signal_out(i_cic));

   cic_decim #(.bw(WIDTH))
     decim_q (.clock(clk),.reset(rst),.enable(ddc_enb),
          .rate(cic_decim_rate),.strobe_in(1'b1),.strobe_out(strobe_cic),
          .signal_in(q_cordic_clip),.signal_out(q_cic));

   // First (small) halfband  24 bit I/O
   small_hb_dec #(.WIDTH(WIDTH)) small_hb_i
     (.clk(clk),.rst(rst),.bypass(~enable_hb1),.run(ddc_enb),
      .stb_in(strobe_cic),.data_in(i_cic),.stb_out(strobe_hb1),.data_out(i_hb1));

   small_hb_dec #(.WIDTH(WIDTH)) small_hb_q
     (.clk(clk),.rst(rst),.bypass(~enable_hb1),.run(ddc_enb),
      .stb_in(strobe_cic),.data_in(q_cic),.stb_out(),.data_out(q_hb1));

   // Second (large) halfband  24 bit I/O
   wire [8:0]  cpi_hb = enable_hb1 ? {cic_decim_rate,1'b0} : {1'b0,cic_decim_rate};
   hb_dec #(.WIDTH(WIDTH)) hb_i
     (.clk(clk),.rst(rst),.bypass(~enable_hb2),.run(ddc_enb),.cpi(cpi_hb),
      .stb_in(strobe_hb1),.data_in(i_hb1),.stb_out(strobe_hb2),.data_out(i_hb2));

   hb_dec #(.WIDTH(WIDTH)) hb_q
     (.clk(clk),.rst(rst),.bypass(~enable_hb2),.run(ddc_enb),.cpi(cpi_hb),
      .stb_in(strobe_hb1),.data_in(q_hb1),.stb_out(),.data_out(q_hb2));


The job of this chain is to decimate a 100MS/s signal down, adjustably, down to rates of 1/512.

Generally, if you just want to use powers of two, you can just use the same halfband filter multiple times; if you're doing it elegantly, you can probably even multiplex the same hardware for multiple iterations.

By the way, coming from a background where sample rates are in the MS/s, I wonder why you need such a low-rate decimation in hardware – every CPU can do that, nowadays, without breaking a sweat.