I've found that situation also when creating LUNs on volumes that the absolute size is used to determine "fit" even if everything is thin with autogrow defined. It's a protection mechanism really - there is a workaround which forces you to take affirmative action that demonstrates you understand what you are doing. A reasonable compromise.
The workaround is simple enough - cheat (sort of). Your volume is 4TB, 2TB used, thin. Destination aggregate has 3TB available space (don't forget to leave some room of course). So set your volume to something like 2.75TB, move it, change it back.
To stress again - this workaround assumes you understand all the consequences of using the workaround. If the destination aggregate only has 3TB available, be sure to account for free space overhard before you move. Be sure you understand the implications of over provisioning this aggregate in your particular use case. All the usual caveats for storage allocation apply.