"Whenever I think Sed or Awk would be correct for a problem..." is a good time to share the problem with HN.
Generally, that rarely happens. We almost never see someone present a text processing problem (input.txt, expected_output.txt) and ask to see what some solutions using UNIX utilties, so that someone might compare with python, for example. Instead, we see endless criticisms of UNIX utilities, without presenting any specific examples (input.txt, expected_output.txt) to ilustrate the unsubstantiated arguments being made.
Without a working example to illustrate a criticism, these criticisms come across as nothing more than worthless opinions. Programmers commenting online provide a lifetime supply of such opinions.
For me, sed is a "daily driver" for text processing. There are numerous small scripts that I use every day that feature sed. I have a folder with hundreds of scripts that use sed. Some use grep and awk as well. However the best program for text processing for me is neither grep, sed nor awk.
It's flex.
If the argument is that python looks like "pseudocode" and sed does not, then I agree. No contest. No examples needed. Someone else long ago decided what "pseudocode" should look like. UNIX utility authors pursued different styles.
If the argument is that python has the best or most libraries, again I would not contest that.
However if the argument is something like "python solutions for text processing
(a) are faster to write,
(b) are smaller,
(c) run faster,
(d) are more robust/reliable,
(e) are quicker/easier to edit ("maintain"),
(f) use less memory/CPU,
(g) have fewer dependencies, or
(h) are easier to read",
then we need to look at the problem in question (input.txt, expected_output.txt). Otherwise we cannot have a meaningful discussion.
Python is just too slow for me. It may be fast enough for someone else, but not for me. Being forced to use python due to a job requirement, using python as a result of pressure from other programmers, or using python because it was "recommended", is not the same as first learning UNIX utilities and then evaluating python. I learned sed and other UNIX utilities first and so any potential "replacement" must offer the same benefits.