I think you might have just got used to it, but it's definitely worse. My job involves consistent writing of 50% Clojure, 40% Java, 3% Kotlin, 3% Scala and another 3% of others (Python, Javascript, HTML, SQL, etc.). And so as I actively code in both Lisp and Algol syntaxes (and wtv Python is), I definitely always miss my structural navigation and editing features in the non-Lisp languages. So I'm guessing you kind of just forgot how nice it is.

Having said that, there's some disadvantages to the Lisp syntax as well, rightward drift due to constant nesting is real, and can make readability and even some edits a lot more annoying, whereas the flatter structure of other syntaxes doesn't have this problem as much. I still find its pros outweighs the cons personally, but your mileage may vary.

Nah, the benefits of structural editing can be nice, but so too are the benefits of a great line-by-line editing workflow ala vim, which makes one just as productive, regardless of language.

And I think that a job where you have to constantly switch between lisp and non-lisp styles would be a lot more frustrating than just using only one style and getting used to it, so I can see your pain there.

I find that the default movement commands in Emacs match Lisp syntax pretty well (although paredit is much better still, when quotes and commas are involved e.g.), but when I switch to C++, they're infuriating. Since I'm editing code written in a programming language and not text written in a natural language the forward-word command can often jump over an entire line worth of C++ tokens, and sometimes it jumps into the middle of a token. This mismatch is really tiresome. Vim commands usually hit closer to the "move by token" motivation, even though it's still just regular expressions. And so editing in it is a breeze (but then it has other disadvantages that deter me from it).

Overall, I don't think you need the full power of paredit when programming. For any given language, your editor movement commands understanding what tokens in this language look like will usually already be sweet and enough.

Oh ya, Emacs default movements aren't great for more line oriented syntaxes, even for s-expressions I have customized things a lot more to my liking and smartparens isn't part of default Emacs either. I don't think Emacs really expect you to stick to defaults, the whole editor is designed to be customized.

When I edit the non s-expressions languages I mentioned I do it in IntelliJ, sometimes with the vim bindings.

In my experience, it's not about being line-oriented. It's about being punctuation heavy or not. Lisp, except parens, for the most part doesn't have all that much punctuation (quotes and commas are rare). Now let's take this program in C++:

  #include <iostream>
  
  int main() {
      std::cout << "hello, world!" << std::endl;
  }

If my cursor is after "main", then M-f will move my cursor to after "std". It completely ignored "()" and "{". Another M-f moves my cursor to after "cout". Here it ignored "::". Another M-f moves the cursor to after "hello" ("<<" and the quote-mark ignored), another to after "world", and another to after "std" (quote-mark and "::" ignored) etc. It behaves similarly when hitting C-Backspace, where sometimes half a line disappears suddenly, because it was punctuation-heavy. I think once I stumbled upon code where it deleted several lines. On the other hand, when I have a variable like "big_number", then Emacs will happily jump into the middle of it. Even though it's an indivisible token in the eyes of the language's lexer. Of course there is a well-known hack of adding the "_" character to be recognised as a "word character". But it doesn't solve the issue really. The issue is that forward-word uses just one set of word-characters, instead of several sets of characters/regexes for different syntactic categories, which would enable jumping first to "cout" and then to "<<".

My experience is that I agree that a standard punctuation is easier to write, but it's harder to get a big picture from it than non-standard.

Anyway, it's way harder to adapt to "parenthesis before the function name vs parenthesis after the function name" and "semicolons after every statement vs. never use semicolons" than "punctuation is all parenthesis and commas (or newline and space as in normal Haskell) vs. punctuation uses the entire keyboard".

Meaningful vs meaningless indentation is also one of the things that don't give me any problems at all to adapt.