This is because you’re using characters that aren’t valid in URLs:
קידום-מנצח
URLs only allow a limited subset of ASCII characters
In order for these characters to work in a URL, they have to be encoded. For example if I visit example.com/foo bar/ the space isn’t valid in URLs, so it gets turned into example.com/foo%20bar/, where %20 is a space character URL encoded.
However, because your slug contains UTF-8 multibyte characters, each of those characters is turned into 2 encoded entities, making it even longer.
So ק becomes %d7%a7, and so on. They are equivalent. Browsers might process these and display the original character in the address bar, but it isn’t possible to have ק directly displayed in a URL at the protocol level.
Similar restrictions happen with domains, requiring a different form of encoding.
So How Do I Get Rid Of This?
You don’t. It’s just how URLs work. Even if you get your hyperlinks to have the characters you want, browsers will translate them back into the entity encoded values.
Some browsers may even see these, and decode them when showing them to the user, but this is purely for the users benefit, the URL hasn’t actually changed.
So, I tested it:
In firefox, I published the post and visited it on the frontend, Firefox went to the URL that was encoded:
http://one.wordpress.test/2020/03/10/%D7%A7%D7%99%D7%93%D7%95%D7%9D-%D7%9E%D7%A0%D7%A6%D7%97/
But if I look in the address bar, it shows the decoded version:
And if I try to copy paste the URL, I get the encoded version, you’ll notice that Firfox shows the correct slug in the status bar, but the markup shows the encoded version:
You can see that they are 2 different ways of representing the same thing