Better how? Switch-statements can be way faster then if/else-chains, specifically if there are many items to check for.
The compiler is free to optimize the switch-statement as he pleases. For a small number of items, the compiler might just produce an if/else-chain in the background. However, if you have like say 20-30 items, then the switch can ie. be converted to a table-lookup, which is way cheaper than having to check perform up to 30 if-conditions.
A reason for using multiple if/elses is mostly if you cannot use a switch, ie. if you are comparing strings, or other non-literal types.
First, you misslead the readers on what switch is. Since switch is named so improper, switch is not a switch, unless there is break keyword instruction in every sub-block of condition .
What switch does is that it evaluates all conditions in their order and executes their subblock if they are true. Logicily switch is equal to this
{// the escape block
if (A){}
if(B){}
if (C){}
{} // the default:
}
If you are sure that A and B and C will always be exclusive by being true, break will save you of only their conditional checks. You can omit default option, or place it in any roder, or you can break only in some code, not other, and create intent enigma hell for any reader of your code, as you have stressed readibility- there is no obvious readibility to switch (just a little hope there is break at every spot, or return, or continue).
Performance is a question of your run-time branching, performed instruction saves, navigating, not at all a question of wheather it was an if or a switch. But frankly, I cannot spot when and how switch can have outperformed proper conditionals in any way on any platform- and by my logic I conclude it cannot.
And to advice beginner programmers with switch for "readability", or "always use"- is a very bad service to them. I know we experienced programmers can even justify GoTo/Label, but doing so in production of your employer will get you fired. The paradox.