Ok. I know i'll get flamed for this. But just do a lil thinking on this first.
Switch is cultural baggage that most new languages feel they have to support to not look odd.
So the main impetus for perpetrating this feature is conformity.
"Why doesnt this language have a switch statement " + puzzled look+ angry loook+ thinking thinking thinking
Decision: dump the language!!
Quick way to get your product ignored in the open minded world of programming is to be different.
So much for programmers being logical and open minded.
The better languages are dead in the dumps . Where is lisp haskell and others that were so well designed and ahead of their time?
ok. back to the topic:
a switch statement is just an if statement in disguise. You know this if you've been programming for a while.
So why call it "switch" and spawn it off as a new concept entirely? y not expand the if function/structure whatever to do what "switch does"?
That way the conceptual load will be lighter on the learner.

By the same token, there's nothing like if-else, if-else-else2 etc.
There's just one if.
That's it.
Most main stream languages are just poorly designed and these poor designs have been shovelled down our throats for so long that we think they're gospel.
In many books, you're told that if is branching.
Then, you're introduced to if.
then more complex if-oxymoronic. There's only IF. ONLY ONE. at athe compiler execution level, there's only1!
because, computers operate in only one of two states - it all resolves to either ON or OFF, 1 or 0,true or false. LEFT OR RIGHT.

Logically a switch statement is faster than a nested if statement with many conditions. A switch statement is faster when you are constantly checking for constant values.

Don't forget that switch statements have fall-through if there is no break in the case of c/c++ . That comes in handy when u want to handle a condition and still want another block of code which is for another condition to run. Can't happen with if
Cheers

Promises and Async/Await

You're all saying the same thing.
Computer scientists say all programs can be written with just branching ,iteration and one other construct.
switch is conceptually,
<condition> <executable>
e.g
look at this switch statement that checks numbers:

 switch(x)
 {
   x=10;
    case 1: <do semething>
   case 2: <do something>
   case 3: <do something else>
 break;
   ....
 default: <do default>
}

 look at an typical if scenario
  if(x==1){}
 else if(x==2){}
 else if(x==3){}
 etc
 so switch is syntactically shorter and more concise that the typical if.

 but theyre conceptually the same.
So why not make an if that takes booleans and other types?

 e.g
 if(true){} -- it takes a boolean as a condition variable.

x=10;
 if(x)
 {
  !: <do something>
 2: <do something else>
 3: <do something else>
}

^
|_______ isnt that what a switch statement is trying to do?!
but students learn only one if- not if that takes booleans,then if that takes non booleans aka switch statement.
No conceptual fragmentation.

my brother the lord is your strength

It's very useful when done properly...
I.e

Switch "j":
Case " a":
Afunc(x)
Case "b":
Bfunc(x)
Default:
Cfunc()

Imagine aAfunc(y){
Switch y:
Case " ai":
Ayfunc(x)
Case "yb":
GBfunc(x)
Default:
Cfounc()
}

Think of how many if and else is Afunc, bFunc cFunc follow this paradigm...
Take a look at Redux Methodology ..... Check our react redux or ngrx angular x with observables (my love).....
Then you will truely understand why some things are better like that.... Using switch with binary logic strategy will even make complex if and else , switch small and beautiful.... If you want to go further and prove never use else statement on If statements and return because if the If statement is true it still checks the else statements (I think in some languages) the solution to that is after executing the logic in the scope you return a value or null depending on the logical flow so that if no conditions are met you can handle that like a Switch fallthrough....
I.e func by(x){
if (x == 1) {
dosomA();
return
}

if ( x == 2) {
dosomeB()
return
}

// no conditions met now handle the fallthrough

throw error or dosomeC()
// get the idea
}

So switch statement is not redundant....

handle the fall through you say?
just tack on a case that isnt matched. that's it.
switch is syntactic sugar for if. nothing else.
So whatever switch is doing is if underneath.

Your talk of switch being less verbose is what i addressed earlier.
switch is conceptually if.
so the if syntax shold be expanded to handle non booleans.

 e.g
 instead of if(<boolean>,<passStatement> , <failStatement>

if can be made more robust:
 if(<distinctiveTypeArgument>,<condition-and executablePairs>
e.g

 if u're using numbersl
 if(x)
 {
 //the pairs gets listed 
//<condition> : <executable>
//e.g
 1: <statement to execute if arg is 1>
2: <statement to execute >
3: <....> 
 .. and so on and so forth
<ifNoMatchFound> : <statementToExecuteIfNoMatchFound>

}

Isnt this what a switch statement is doing?
I've demonstrated that if can do the same, without rewording the syntax.
NO unnecessary conceptual overload.
The syntax and concepts are not splintered off unncessarily.
The whole syntax is uniform and streamlined.

When you're if'ing with booleans, you know you're doing so.
when the condition variables isnt a boolean, no problem,he if statement is robust enough to handle that.
You dont go the roundabout route using a disguised if ,called a 'switch' statement.

Interesting...

Personally, I avoid conditional statements when I can.

As a rule, it is the first pattern I follow.

I believe JS has

try {}
catch{}

and python has the

try:
except:

Take this example:

A man (interpreter/compiler) is always standing at the door. Waiting for orders.

you come to the door, and ask for water, and it is available.

Using conditions
you: do you have water.
man: yes
you: get me a glass

Using try
you: get me water
man: here you go.