Able to reproduce the issue on the reported chrome version stable 61.0.3163.100 and on latest canary 63.0.3238.0 on Windows10, Ubuntu 14.04 and on Mac 10.12.6. As the issue is seen from M50(50.0.2634.0), hence considering it as Non-regression and marking this as Untriaged

What are other browsers' behaviors and what the spec say?

FF 57.0.1 doesn't have an up-down arrow for input[type=date]

It's datepicker grays out dates occurring before min and after max (as does Chrome's)

Safari doesn't have a specific implementation for input[type=date]. Seems like it's treated as an input[type=text]
Don't have access to a Windows VM or machine at the moment.

I seem to remember at the time I filed this bug that Chrome's up-down arrows honored the min attribute (wouldn't reduce the month below min) but now they don't honor max or min. 

Here's a fiddle for min: https://jsfiddle.net/f1ppuzyf/1/

I don't think the spec mentions behavior for an up-down arrow for input[type=date] at all but I may be looking in the wrong place.

https://html.spec.whatwg.org/multipage/input.html#date-state-(type=date)
https://html.spec.whatwg.org/multipage/input.html#input-impl-notes

Editorial:

At the time I filed this bug it was because I believed the behavior of max and min wasn't consistent with each other (i.e. you could set dates higher than max but not less than min using clickable up-down arrows). 

I also see the reason why using keyboard up-down arrow keys might need to allow setting individual month, day or year fields outside of the ranges, for accessibility reasons e.g. I want to set 1 Dec 2012 when max is 1 Oct 2013, it would be annoying to set the year first then tab back to set the month. Allowing setting the month to 12 first then tabbing once to set the year is more convenient. So I understand the need for this behavior with keyboard operation.

The up-down arrows in the control are clicked by mouse so (from an accessibility standpoint) I'm not convinced they need to have the same behavior as keyboard up-down arrow keys. I think their behavior should be consistent with the behavior of the dropdown datepicker.

This is by design.  We restrict only the first editable sub-field.
We thought up-down arrow keys and spin-buttons should be consistent. I guess people have different opinions on this UX, and it's difficult to make everyone happy.