When serializing a single integer, int.to_bytes and int.from_bytes are more efficient alternatives to struct.pack and struct.unpack. However, struct.pack and struct.unpack currently have the advantage that the byteorder does not have to be specified (because it defaults to sys.byteorder). It would avoid a lot of redundant code to make the byteorder argument default to sys.byteorder in int.to_bytes and int.from_bytes too.

to_bytes and from_bytes aren't remotely related to native primitive types, struct is. If the associated lengths aren't 2, 4 or 8, there is no real correlation with system level primitives, and providing these defaults makes it easy to accidentally write non-portable code.

Providing a default might make sense, but if you do, it should be a fixed default (so output is portable). Making it depend on the system byte order for no real reason aside from "so I can do struct-like things faster in a non-struct way" is not a valid reason to make a behavior both implicit and inconsistent.

It may be acceptable to allow for byteorder="native", but making the default native will make it too easy for people to write code that works great on their machine but not machines with the opposite endianess. Byte order is something you should explicitly think about everything you serialize an integer. So, I'm going to reject this proposal as stated.