Now, this tries standard syntax first and then falls back to browser based extension.
This may be a misleading statement. A compliant browser will try the standard unprefixed property first, but if it also supports the prefixed property in addition to the standard, then it will apply that prefix as well. This usually results in the standard declaration being overridden by the prefixed declaration and a browser's potentially non-standard implementation of that property, defeating the purpose of having the standard property there in the first place.
The reason why you should declare the unprefixed property last is because that's how properties cascade in a rule: a browser will always use the last applicable one. Prefixed and unprefixed versions of a property are treated as the same property with respect to the cascade, so you want a browser to do its best to adhere to the standards when applying that property.1
If a browser implements a prefix but not the standard, that's fine, but if it implements both, you want to ensure it uses the standard instead. You do this by declaring the standard property last.
1 As far as I'm aware this is not dictated by the spec, because as far as the spec is concerned vendor extensions are non-standard and so their implementation cannot be described. Although the syntax of vendor prefixes is described in the spec, implementations are left entirely up to the discretion of vendors.
However it's an agreed-upon convention by most browser developers when implementing prefixed versions of a to-be-standardized property or rule, to always treat both prefixed and unprefixed versions as aliases of each other.