You can encode the dot (.) and slash (/), but in this case, they have meaning as themselves. If the folder path component had a slash (/) in it (as opposed to slash being used to seperate components), then encoding it as %2F would probably be necessary.
Encoding strings, encoding URLs, encoding scripts, etc, it always an exceptionally complex issue. Some parts must be encoded, some parts must not.
The purpose of the filter is to remove the “special” nature of every character in the encoded component. But you cannot use that on the entire URL, since some characters actually do have a special meaning.
Which ones have special meaning and which ones don't needs to be known in order to know which parts need to be encoded.
This hasn't changed from the pre-9.0 variant - in all cases, you have to encode only the special characters that need to not have a special meaning.
In the URL above, the colon, slash and dot all have special meanings and cannot be encoded. The parts between the dots and slashes is plain text, and any special characters need to be encoded (and as I mentioned above, if one of those components contained a colon, slash or dot that was meant to be part of its name, then it probably would need to be encoded).
The same thing applies for http: URLs. The colons and slashes and ? has a meaning, as does potentially the = and & in the query. Other characters will generally need encoding.
The filter is not magic, it just facilitates the act of encoding the characters. It doesn't know which bits might need to be encoded and which bits don't - and indeed you cannot know that after the URL is constructed. You must do that while constructing the URL. Otherwise you cannot tell which characters of the URL are intended to be special and which not.
For example, a URL without any encoding applied to it like this:
https://www.stairways.com/folder?query
There is no way to know whether that refers to page folder and query at query, or it refers to page folder?query (which is a perfectly valid file name on many systems).