I haven't read the paper, it's probably well beyond me, but I have always felt that the presumed existence of a singularity had to be the result of incomplete theory.
No one is picking Nodejs for high performance, but when it is chosen for other reasons it's still expected to perform well. The Nodejs gRPC library performs poorly relatively to the overall performance characteristics of Nodejs, and this is a problem because most of the work performed by typical Nodejs services is API-related work (sending data, encoding and decoding payloads, managing sockets etc). That's not even touching on the bugs in the http2 implementation in node core or the grpc library itself, but much of the selling point of gRPC is supposedly the language interop, and this seems like false advertising to me.
I dislike the use of gRPC within the data center. People reach for it citing performance, but gRPC is not high performance and the quality of the available open source clients is very poor, particularly outside of the core C++/Java implementations like the nodejs implementation. I am not against the use of protobuf as an API spec but it should be possible to use it with a framing protocol over TCP, there just isn't a clear dominant choice for that way of doing RPC. When it comes to web based APIs I am more in favour of readable payloads, but there are issues here since we tend to use JSON but the type specificity is loose, which leads to interop problems between backend languages, particularly in nodejs where JSON parse is used to implement a schema mapping. In order to do this properly, encoders and decoders need to be generated explicitly from schemas, which somewhat diminishes the use of JSON within the context of JS.
If using the debugger is less efficient than using printf then it's a symptom of a wider problem. To be clear though, "printf debugging" is not the same thing as adding structured debug logs to your service and enabling it on demand via some config. Most production services should never be logging unstructured output to stdout. Printf debugging is just throwing out some text to stdout, and it generally means running unit tests locally and iterating through an (add printf, run test, add more printf) loop until the bug is found. Unfortunately it's the default way to debug locally reproducible bugs for so many engineers. So while I don't see the point in not using printf for purely ideological reasons, I avoid building software where this is the simplest option and use the service's structured logger if not easily reproducible. I also generally think it's bad to default to printf debugging in the way I have defined it here and find that competent use of debugger is more often a faster way to debug.
They think you're a poor performer in your assigned role and it's because you're too interested in the code. They assume you can do the job if they remove the distraction.
Or:
Your manager knows you want to go over to software engineering and if you appear to know and understand the codebase you could be poached to the other team.
Either way it looks like your manager wants you to fit the role you have been given and to stay there. The anxiety about linkedin points to this. You expressed preferences to be doing something else. You're a flight risk and they are trying to limit your options.
Edit in some unsolicited advice:
You don't need to quit over this but you should quit your job if it's not leading you to where you want your career to be, which it obviously isn't. The first 10 years of experience sets you up for your career beyond that and if it's going in a direction you don't enjoy you're going to be miserable in your job. Find a development job if that's where you want your career to go, there is no time to waste.