There are many advantages. Here are some:

  >>> class MyEnum(Enum):
  ...   VALUE_ONE, VALUE_TWO, VALUE_THREE = range(3)
  ... 
  >>> v = MyEnum.VALUE_ONE
  >>> v == 0
  False
  >>> v == MyEnum.VALUE_ONE
  True
  >>> type(v)
  <enum 'MyEnum'>
  >>> isinstance(v, MyEnum)
  True
  >>> print(v)
  MyEnum.VALUE_ONE
  >>>

Now try to think how these would result if you'd defined VALUE_ONE... your way.

Because if you read the function signature of a function like def fill_rectangle(color) you haven't got the slightest idea what valid values of "color" is. (Ignore the fact that python doesn't have types in the function signature to start with, say you're reading the documentation instead)

If you knew that color was of the enum-type my_gui_lib.standard_colors you know exactly which colors you can use and you can reuse them for fill_ellipse also because it most likely uses the same type. Instead of every function having to reiterate all valid integer values of color or referring to some table. Your editor will also provide you with auto complete of valid values unless you're coding in notepad.

In a type safe language you will even get compilation error if you provide a type/value out of range but since python is dynamic this would be hard. It's simply impossible to pass the function an invalid value, which is invaluable. So in python the value added isn't a strong as in a strong language but it's still there.

To expand on what the other poster said: VALUE_ONE, VALUE_TWO and VALUE_THREE are ints. That is their type. In most cases, though, groups of constants have some conceptual type that is entirely separate from integers. It's nice to formalize that concept in our code with an actual type. That way, when we say a function accept that type, we can't also pass it a random integer. Or returns that type, we can't return a random integer.

Isn't it one of the core Python values that functions don't contract to accept, or return, particular types at all?

There's no enforced contract for a particular type, but a way to create entirely new values that have no relation to any existing value. I.e. you compare a value to MyEnum.SpecialUndefined and are sure that no None or 0 will yield True. OTOH, if someone would be determined to create a thing with the same conceptual sense as SpecialUndefined, he could explicitly define that it is Equal to MyEnum.SpecialUndefined.

In C/C++, with you use an enum type in a switch, the compiled will warn you if you are missing one. If you pass an enum type as argument, there will be a compile time check if the constant is part of the enum (you can force them, but it is not the point). Having a grouped set of constants also make sense in an organizational POV. In Java, enums are classes while in C/C++ they are only a set of constants. Enums in different languages are implemented differently and have various kind of extra features. But deep down, they always serve the purpose of storing a related set of constants.