mongodb read data from secondary hidden replicaset
Hidden replica set members are invisible to client applications via replica set or mongos connections so all three of your examples are working as designed.
As per the documentation on Hidden Replica Set Members:

Clients will not distribute reads with the appropriate read preference to hidden members. As a result, these members receive no traffic other than basic replication. Use hidden members for dedicated tasks such as reporting and backups. Delayed members should be hidden.
In a sharded cluster, mongos do not interact with hidden members.

You can only connect to a hidden member directly (i.e. by specifying a single hostname and port). Read preferences and tags are ignored for direct connections.
For example, any of the following should work assuming server1-replica-3 is a resolvable hostname and you aren't blocked by firewall configuration:
 mongo server1-replica-3:27018
 mongo --host server1-replica-3 --port 27018
 mongo mongodb://server1-replica-3:27018

If you have a sharded cluster with multiple hidden members, you can only read from one hidden member at a time via a direct connection. Note that bypassing mongos with a direct connection to a hidden secondary may return stale or orphaned data for a sharded collection.
If you want to dedicate nodes for specific read use cases in a sharded cluster, instead of making these hidden you should use secondary read preferences with replica tag sets. Be aware that reading from secondaries may return stale, duplicate, or orphaned data for a sharded collection as at MongoDB 3.4. For more background, see SERVER-5931: secondary reads in sharded clusters need stronger consistency. An improvement for SERVER-5931 was recently committed to the MongoDB 3.5 development branch, so secondary reads in sharded clusters should be safer in the MongoDB 3.6 production release (expected later this year).