They're not being treated differently.
As explained in the answers to the original question, if a malicious site had a script that requested //127.0.0.1/private.txt, they would not be able to read that file. However, what was glossed over is that your browser would still make the request to your local web server.
The only protection that Cross-Origin Resource Sharing (CORS) provides, in the context that you're asking, is the malicious script will not be able to read the data in your file.
In the answers on the original question, we are warned that even though the malicious site could not get the data from that file, they can still cause side effects. The example that we are given, where a router's admin panel was exploited in order to give external access, was simply an arbitrary example where someone can cause damage within the secure parts of a home network, even if they can not get data from that.
In the example, if (instead of simply trying to read sensitive information) the malicious site caused you to load //127.0.0.1/deletePrivate_txt.php, your browser will make that request to your local web server. They won't be able to read the results of that request, but the request will still happen, and whatever side-effects that this script has (such as deleting every diary entry since 1958) will happen as well.
CORS protects sites from reading sensitive information, regardless of the IP address of the web server. However, CORS does not (and is not designed to) protect against Cross-Site Request Forgery (CSRF).
