Can't we have the code doing the display just use the aggregation name rather than relying on the order?

The internals of the Search code combines the originally specified Aggregations into the Aggregation results array, so that there is a single array that contains both the settings as specified in Jetpack_Search::set_filters(), and the resulting 'buckets' returned by ES. This all happens in Jetpack_Search::get_filters(), which is what the Widget ends up calling before running a foreach() on them.

It would be possible to re-sort them at the Widget level, but it's better having them in the 'expected' order (as defined by site developer) everywhere, so it's consistent regardless of how the module is used - in both the Widget, but also any custom code that builds upon Jetpack_Search::get_filters() directly.

Also I should give a demo of the problem. Say you do this:

Jetpack_Search::instance()->set_filters(array(
		'Month' => array(
			'type'     => 'date_histogram',
			'field'    => 'post_date',
			'interval' => 'month',
			'count'    => 10,
		),
		'Year' => array(
			'type'     => 'date_histogram',
			'field'    => 'post_date',
			'interval' => 'year',
			'count'    => 10,
		),
		'Categories' => array(
			'type'     => 'taxonomy',
			'taxonomy' => 'category',
			'count'    => 10,
		),
	) );

The Aggregations that get returned in the ES result aren't necessarily in the same order, so you could end up with an array like this:

array(
    'Year' => array( ... ),
    'Categories' => array( ... ),
    'Month' => array( ... ),
)

Then when the Widget renders, the ordering is 'off' and it's not possible to control the display order.