Maybe. But endless discussions like this one are very draining for the few core devs who still try to help people develop their ideas. There’s a reason it’s hard to get core dev attention on the ideas category - it’s got a reputation of having a pretty bad signal to noise ratio 
Whether that’s a negative view, I can’t say. But it’s a reality that keeping discussions focused and short, and not endlessly relitigating the same points, would improve things for everyone.
I’m sorry if you think it’s unfair, but it’s genuinely difficult to get across to people that if they don’t represent the costs and benefits accurately, they won’t get support and their proposal will go nowhere. I can’t even tell you how often I’ve had to list all of the “hidden” costs of something that’s being claimed as “just a few lines of code”. It’s frustrating to have to keep doing so, and even more frustrating to be challenged whenever I do.
You seem to have a mistaken view of how Python development works. Generally, I’d expect the person proposing the idea to provide the implementation, including documentation and tests, in the form of a PR. It’s very rare for someone on the core team to see an idea here and go off and implement it (not unheard of, but certainly rare). So the proposer typically needs to do the work, and that means they should get familiar with what will actually be involved. For example, in this case, the str type is written in C, so a new method will need to be written in C. That’s a barrier right there - many people around here don’t know C, so the likely assumption when someone says “this is easy to implement” and shows a Python implementation is that they won’t be able to do the actual coding themselves, and they probably don’t have a good feel for the implementation difficulty of a C version.
I agree with all of this, although I’d say pformat might ameliorate the foot-guns (and I’d skip the “low cost” comment because it’s potentially controversial and will be established later in the process).
But where do we go now? Who will write the PR to implement this? As a change to a core type, it’s likely to need a PEP as well. Who will write the PEP, and do they have a core developer willing to sponsor it? Getting a sponsor isn’t always easy - it requires a core developer who’s willing to mentor the contributor through the PEP process, which is potentially a chunk of work (especially if the contributor hasn’t already shown a good awareness of the sort of issues they’ll need to cover in the PEP).
Maybe this all does sound negative. I’m sorry if that’s the case. The process is quite laborious, but that’s because we have a responsibility to the literally millions of Python programmers out there, to not break their code, and to act as careful custodians of the language. The days when a change to Python could be low-impact are long gone, I’m afraid.
Language changes can and do happen. Not just big ones like free threading or the JIT, but smaller ones as well - yes, even just adding small convenience methods. But much more often than not, they happen as a result of people stepping up and doing the work, and following the process with a good awareness of the impact of the changes they are making. Quiet changes that are offered without getting sucked into controversial debates. Discussions that quickly build consensus and then move onto implementing the agreed changes. Long, controversial threads like this one (and the one that spawned it) are much less likely to produce viable changes, in my experience.