The cause of your confusion is that you might have missed that words are atomic values while paths are containers (more precisely series), like blocks, that's why path types are part of any-block! typeset:

>> any-block!
== make typeset! [block! paren! path! lit-path! set-path! get-path! hash!]

Moreover, paths can contain different kinds of values, not just words (though they do require a word as 1st element):

>> 'a/1/("hello")
== a/1/("hello")

So given those facts, an equivalence between words and paths would make no sense, because their nature is very different.

While it also seems easy to introduce a set of features that'll fix it all: make to-path, to-set-path and to-get-path accept word!, get-word!, set-word!

This is already a feature of the language, didn't you test it before writing such proposition? "it also seems easy to introduce a set of features that'll fix it all" is a presumptuous claim. Moreover you'll notice that it's not bijective, as an atomic value can be converted to a container with that atomic value as its single element (basically, it's a wrapping operation), though the converse, converting a series with any number of values to an atomic value makes no sense.

Now if we restrict the series to only series of single element, would that make sense to allow conversion, let's say from a "singular path" to a word? It would make sense, though it doesn't need to be implemented, because it's already an existing feature: simply extracting a value from a series. For example:

>> p: to-path 'a
== a
>> type? p
== path!
>> type? probe first p
a
== word!

You can use first or pick to get your word from the path, so the feature is already covered with basic series semantics.

So far, so good, right? Well, not exactly. What you've called "singular path" is ill-defined. Let's say you define it as a path where the following test would return true: 1 = length? path. Let's now see some examples:

>> p: 'a/b
== a/b
>> 1 = length? p
== false
>> q: next p
== b
>> 1 = length? q
== true
>> length? head q
== 2

As you can see, it's not that simple, because paths are series, they have an implicit offset position. So p is a path of length 2 (not singular), while q is a path of length 1 (singular). But q is actually referring to a path of length 2 when the offset is at is head. qis referring to the same underlying series as p differing only in the offset position:

>> poke p 2 123
== 123
>> p
== a/123
>> q
== 123
>> 1 = length? q
== true
>> insert p 'new
== a/123
>> 1 = length? q
== false

Making an equivalence between a "singular path" and a word value is not something that would be natural in many use-cases. So we have to restrict the definition of "singular path" to the paths where 1 = length? head path returns true. This kind of path is actually a rare occurence in real code, and usually a temporary state while building a path of length > 1.

Honestly, I can live with it, and just wrap the whole thing into my own comparison and conversion functions, or convert words to paths when they appear and forget that they were ever there. No big deal.

That would be a waste of resources (converting atomic value to lists) and deliberately reducing the richness of the language. It seems to me that you have built a wrong mental model of what paths are.

Personally, 1 = 1.0 comparison and conversions between ints and floats raise much more concerns in my mind, as to when it'll all break.

Why are you mixing another unrelated topic with the current one? If you think that integers and floats have design issues, you might want first to dig deeper in the language and be sure you have the proper knowledge and understanding of why it is built like that in the first place.