Is readability a valid reason to NOT using const in parameters?

Readability is a valid reason to learn to use whitespace:

void MyClass::myFunction(
        const MyObject& obj,
        const string& s1,
        const string& s2,
        const string& s3
) {
    return;
}

Located over there the parameters won't get confused with the body of the function. By locating them on a different line you won't have to reposition them when you change the name of myFunction to something more descriptive. Not changing the parameters position when they haven't changed is something source control diff tools will appreciate.

const means something. Don't throw it out just because you're out of space and ideas. Readability is king but breaking things in it's name is just giving up.

Actually, the readability issue definitely goes the other direction. First, you can trivially solve your run-on line by the use of whitespace. But removing const doesn't just make the line shorter, it completely changes the meaning of the program.

Herb Sutter refers to the const in reference to const as the most important const because a reference to const can bind to a temporary and extend its lifetime. An lvalue reference to non-const cannot, you need a separate variable.

void foo_const(std::string const& );
void foo_nc(std::string& );

std::string some_getter();

foo_const(some_getter());      // OK
foo_const("Hello there"); // OK

foo_nc(some_getter()); // error
foo_nc("Nope");   // error

std::string x = some_getter(); // have to do this
foo_nc(x);                     // ok
std::string msg = "Really??";  // and this
foo_nc(msg);                   // ok

What this means for usability is that you'll have to introduce all these temporary variables just to be able to call your function. That's not great for readability, since these variables are meaningless and exist only because your signature is wrong.

Simple answer is "no".

The long answer is that the const keyword is part of the contract the function offers; it tells you that the argument will not be modified. The moment you remove the const that guarantee goes out of the window. Remember that you can't reasonably maintain the constness (or any other property) of something using documentation, conventions, or guidelines - if the constness is not enforced by the compiler, someone will think that they can make their work easier if they fiddle with the parameter "just a little bit". Consider:

// parameter "foo" is not modified
void fna(Foo& foo);

void fnb(const Foo& foo);

Apart from the fact that the latter version is more concise, it also provides stronger contract, and lets the compiler help you maintain your intentions. The former does nothing to prevent the fna(Foo&) function from modifying the parameter you pass to it.

As in @CandiedOrange answer, you can use whitespace to lay out the code and enhance readability.

Removing the const keyword removes readability because const communicates information to the reader and the compiler.
Reducing the horizontal length of code is good (nobody likes scrolling sideways) but there's more to const than text. You could rewrite it:

typedef string str;
typedef MyObject MObj;
void MyClass::myFunction(const MObj& o,const str& s1,const str& s2,const str& s3)

Which doesn't change the contract but fulfils the need to reduce line length. Truly I would consider the above snippet to be less readable and would opt for using more whitespace as already mentioned in CandiedOrange's answer.

const is a functionality of the code itself. You wouldn't make the function a non-member to remove the MyClass:: section of the declaration, so don't remove the const

As long as possible it is better to keep const visible. It improves code maintenance a lot (no guesswork to see if this method changes my arguments).

If I see lot of arguments in a method, it forces me to consider creation of project based jaron (Matrix, Employee, Rectangle, Account) that would be much shorter, easier to understand (eliminates long list of arguments to methods).