Take what I say with more than a grain of salt as I don't have any experience working at an all-JS/TS shop. The backend capabilities and frameworks for js/ts has certainly improved but working as a sr dev at a monotech-stack company wouldn't be my first choice. I understand why it's done as it's hard to find good candidates in many areas and there are more dev with experience in js than anything else.
For that reason alone, if you want to master being a backend dev, I would suggest that you learn something else. It's more likely you'd be working with people with deep backend experience to learn from, and you distinguish yourself from the many js/ts/fullstack-backend devs. Of course, still grow and apply new principles to your js/ts work. It is possible that with number of companies that use a js/ts stack that some of them will be well known as having a concentration of great engineers. I can't guess how many or when that would be, so I'd bet on what's known today.
The reason to learn something else isn't only for your future career, learning different styles ecosystems makes you a better dev in you current one. The common aspects that people consider are: (1) dynamic vs static typed, (2) degrees of 'compiled', (3) garbage-collected, 'flavoured' (Rust), ref-counted, explicit memory management, (4) single-thread, fibres, multithreaded, or actors kinds of concurrency, (5) lisp, FP, or procedurally structured.
So of those, js/ts covers a bit of (1) and (2). Using finer-grained memory management is about low-level performance and there are very few places that's a big factor. It can be interesting but rarely applicable in most day jobs. I would definitely explore using an FP style with lots of filter/map, higher order function composition and using static types to represent logical states. Best done in a language with type inference but could be done to some degree in TS. Lisp is always interesting, but it wasn't for me--I couldn't imagine enjoying working with another person's (or a large team's) codebase.
[Edit: I also recommend building some front ends to consume your backends and be able to build-out hobby projects--it's hard to get good at designing APIs if you never feel the pain using the ones you make. I tend to use either Vue for web, or Flutter/Dart for mobile.]
As for Go or Rust in 20 years? That's a long time and if I had to bet I'd bet on Go getting better rather than Rust becoming fully mainstream. OTOH, I can see Rust owning actual low-level systems programming and Go being replaced by languages with fewer warts. I would still recommend learning Go now as it is a cognitive reset showing how simple things can, and ought to be--if perhaps a bit verbose at the moment without generics. It's not my favorite language but still a top pick for smaller projects.