Wow, I wasn't convinced there was a problem, but I did some testing and discovered that you are correct. And as Tamura says, what you describe would indeed be a WikiTree GEDCOM export bug.
In my own experiments today, I noticed that the CONT and CONC tags are strictly cutoff at 78 characters without regard to word boundaries. The exported GEDCOM sets the CHAR to UTF-8, and many of the profiles do include many multi-byte characters. But initially, none of my exports encountered this problem, though a few of the lines were really close. I was just randomly lucky. Turns out, the lines are also cutoff without regard to multi-byte character boundaries either.
The 'file' command will show when its a problem or not:
$ file -bk --mime-encoding goodexport.ged
$ file -bk --mime-encoding badexport.ged
This perl command will help identify which line number, character number on the line where the non-ACSII character occurs:
$ perl -ne '/^([\x00-\x7f\xa0-\xff]*)(.*)$/;print "$.:".($-+1).":$_" if length($2)' mygedcomfile.ged
So I found one of my profiles that was really close, and added (in blue below) just enough characters to the line to cause the GEDCOM export to split the mylti-byte character as you describe.
See https://www.wikitree.com/wiki/Brownlow-71 (the second, and current test edit). It splits the 3-byte em-dash across the lines.
Affected line(s) as displayed in emacs text editor:
2 CONC an]], son-in-law)<ref name="death">Texas, Death Certificates,123 1903\342
2 CONC \200\2231982</ref>
So, it is possible to find and correct the offending profiles using this workaround, though its a bit tedious having to do multiple exports and testing.