If you can't guarantee that the data to be merged is focused at the most recent data, you have to consider the following example:

Data2010

Data2011

Data2012

Data2013

What happens in your system if you now try to merge more 2010 data (for whatever reason)?

New rows would appear of course.

Keep in mind: these new rows would appear regardless of if the table is partitioned.

Partitioning might put them into the 2011 dataset (depending on how you set up your partition functions)

But with sizable data like you mention (360GB) - you will need a sufficient maintenance window to process logged deletes. If you don't have that window, partitioning will be your only way to "keep up" with rolling purging.

In the example above, it's really not that bad to "add" more 2010 data. It may hang around for a year, but it will eventually purge.

The merge issue you give would not stop me from partitioning this table if otherwise partitioning was a good fit.

Partitioning does add complexity to managing the system. But it's hard to beat for rolling purges of data if the table qualifies to be partitioned.

Are there other concerns?