On one hand, I agree that the situation isn't intuitive. Why should some methods of bytearray accept bytearrays, and some shouldn't?

On the other hand, this actually has rather deep implementation reasons. 

Methods like 'translate' are implemented in Objects/bytearrayobject.c

On the other hand, ljust, rjust and center are taken from stringlib. Now, stringlib is generic code, and has some strict argument checking. For example, in stringlib_ljust:

    if (!PyArg_ParseTuple(args, "n|c:ljust", &width, &fillchar))
        return NULL;

The 'c' format to PyArg_ParseTuple expects an object that passes PyBytes_Check, IOW a bytes object or a subclass thereof. bytearray is not a subclass of bytes, hence the problem.

The solution could be global, to allow bytearray fit the 'c' format of PyArg_ParseTuple. Then one would also be able to pass a bytearray into other stringlib methods requiring the 'c' format.

One way or the other, this is of course doable. A decision has to be made though - is the nuisance annoying enough to warrant such an API change?