That's the easy part, yes.
But each editor also has its issues with generating "backend html" doing bunch of wonky stuff so it works for this editor — using that text in various other places and when you have multiple rich text fields and not single big one to edit whole document is always a major PITA.
Then you get whatever they write to PDF report so for example you have to render HTML correctly there. Amount of ways it can break is basically infinite, getting paragraphs page breaks is non trivial amount of work, especially when customer wants their own layout for the report and not generic looking or just broken layout. So problem is mix and match display of whatever they write in different places.
Not to mention, everyone wants prefilled templates, so they don't start from scratch, oh and your templates need to have dynamically filled in placeholders, now you have to put something like tags that will be updated by your back end.
Maybe you need to send it via API and all kind of companies have WAF on incoming/outgoing data then you have to strip tags.
Yes you can encode/decode, limit options, white list allowed tags, and I was doing that for years now, but amount of things that break is still big and another customer wants you to enable lists when you wanted to
support just italic, bold, then you have whole blast radius and feature creep is real.
ROI is just not there, as I mentioned no one wants to specifically pay for all that, we have a really good run telling customers to just use plain text, amount of regressions to be tested, amount of expectations of things to work out of the box once you go with rich text is really high.
Bar to jump to is basically re-implement MS Word — oh did I mention everyone will expect copy pasting from Word to work perfectly - just imagine how much time your customer support has to spend explaining you limited options in that field to be just bold and italic.