There are a few reasons, most of which are variations of "they're being lazy."
First, you probably don't need to touch the port number and associated integers. They're integers. They're treated as integers by the processor and only the host uses the number, so it's always correct. In fact, if two machines with different byte-orderings open port 12000 the way you cite, they can't connect, because htons(12000) is going to be 12000 on one machine (0x2EE0) and 57390 on the other (0xE02E).
Generally, examples pass ASCII strings from client to server (or vice versa) with send() and recv(), which don't need conversion to/from network byte ordering, because each character fits in a single byte; remember that those macros change the byte ordering, so a byte is a byte. If you send anything bigger, though, you absolutely should "externalize" your data.
Lastly, if you can guarantee that everybody is running on a processor with the same architecture, you technically don't need network-ordering, because both processors will read the byte order the same. Please don't rely on this, but if you test without the conversion and everything works out fine, that's why.
The correct behavior is that, if you're sending an integer outside of your program, you should use htons() or htonl() on it, first. If you're receiving an integer, you should use ntohs() or ntohl(). Anything inside your program or taking up a single byte, you leave alone.
Anything else, you leave alone, provided the languages use the same encoding (i.e., a C-like, NULL-terminated string or an IEEE 754 floating-point number). If not, you need to write code to externalize the data or use a library like in RPC or CORBA.
