SNMP management stations can request information from agents via SNMP. SNMP management stations can also control certain functions of the device. Devices can also report urgent information (for example, that a line has gone down, or that a significant number of errors are occurring on a given line) to management stations via SNMP. Devices vary greatly in the sorts of information they give out via SNMP, and in the parameters that can be changed via SNMP. The network devices that originally spoke SNMP used it for mildly sensitive data, like the number of bytes that had gone through a specific port, or the routing table of a given device. Some of them allowed management stations to do potentially catastrophic things (turning off a network interface, for instance), but most of them didn't (if only because many of them simply failed to implement the "set" command, which is required for a management station to actually change anything).
Modern SNMP agents often contain extremely sensitive data; the default SNMP agent for Windows NT includes the complete list of valid usernames on the machine and a list of currently running services, for instance. Many SNMP agents allow for machine reboots and other critical changes. Unfortunately, they are hardly secured at all. SNMP security currently relies on a cleartext password, known as a community string, with a well-known and widely used default. Some SNMP agents implement additional levels of security (for instance, controls over the IP addresses they will accept queries from), but these are still insufficient for extremely sensitive data. Allowing SNMP from the Internet is extremely dangerous.
With the introduction of SNMP v3, which provides better authentication and can encrypt data, it is becoming possible to run SNMP more securely. However, SNMP v3 is not yet widespread.
If you interfere with a host's routing, you interfere with its ability to talk to the rest of the world. You can cut it off altogether or merely steal traffic that was intended to go someplace else. Unfortunately, most routing protocols now in use were designed when the Internet was a less dangerous place, and they don't provide any significant degree of protection.
The good news is that routing information rarely needs to go to any significant number of hosts; in general, you will have at most a few routers that talk to the Internet, and those will be the only hosts that need to talk routing protocols to the Internet. In general, you will not need to pass routing protocols through firewalls, unless you are using internal firewalls inside a site.
ping simply tests reachability; it tells you whether or not you can get a packet to and from a given host, and often additional information like how long it took the packet to make the round trip. traceroute tells you not only whether you can reach a given host (and whether it can answer), but also the route your packets take to get to that host; this is very useful in analyzing and debugging network trouble somewhere between you and some destination.
Because there aren't servers for ping and traceroute, you can't simply decide not to turn the servers on. However, you can use packet filtering to prevent them from reaching your machines. There are few risks for outbound ping or traceroute, and those risks can be avoided by using them without hostname resolution. Inbound ping and traceroute, however, pose significant risks. ping, in particular, is a frequent basis for denial of service attacks. ping and traceroute can both be used to determine which hosts at your site exist, as a preliminary step to attacking them. For this reason, many sites either prevent or limit the relevant packets inbound.
You do not have to use NTP across the Internet; it will synchronize clocks to each other within your site, if that's all you want. The reason that people use NTP from the Internet is that a number of hosts with extremely accurate clocks -- radio clocks that receive the time signal from master atomic clocks or from the atomic clocks in the Global Positioning System (GPS) satellites -- provide NTP service to make certain that your clocks are not only synchronous with each other but also correct. Without an external time service, you might find that all your computers have exactly the same wrong time. Accepting an external service makes you vulnerable to spoofing, but because NTP won't move the clocks very far very fast, a spoofed external clock is unlikely to make you vulnerable to a playback attack, although it could succeed in annoying you by running all your clocks slow or fast. Radio or GPS clocks suitable for use as NTP time sources are not terribly expensive, however, and if you are using NTP to synchronize clocks for an authentication protocol like Kerberos, you should buy your own and provide all time service internally, instead of using an external reference.