The HDMI switch has an "original price" of $250 in the same sense that a car has a sticker price. Monoprice is not a clearance site; if you want to pay $150 to someone else, you're free to do so.
HDMI does indeed support addressing. You may want to read up on the standard before you begin claiming things that aren't true. Any HDMI device can communicate with any other over the HDMI system, although no one has built a switch that handles things in such a manner because there's no demand for such a product (as I'll explain in a bit).
I didn't go looking for an industrial part because there's no pricing available. There never is for products where the purchaser is expected to buy in lots of 1,000. The conexant chips you linked have A) no price listed and B) don't support HD resolution, so they're a moot point anyway.
What I did link was a product with the necessary industrial hardware buried inside. If we ignore the D/A converter (those are dirt cheap anyway), the USB chipset, and the fan (yes, fan) necessary to keep the compression hardware cool, then we can make a reasonable approximation of the cost of the HD compression hardware inside. If you can find an HD capable industrial part, including the price, please feel free to link it.
By the way, compression chips don't care if they're taking digital input from a source that was originally digital or digital input from a D/A converter. It's already digital by the time it hits the compression hardware. There might be a tiny, miniscule hit in speed due to the digital video from the D/A converter having slight imperfections, but it's pretty nominal.
Here we have a $200 box. Let's say that $100 of it is due to the unnecessary D/A equipment, USB hardware, and the enclosure itself. Hell, I'll be super generous and say that only $50 of that device is the actual compression chip. Now you're telling me that we should have a $50 encoder chip in a $200 Xbox 360 or a $400 PS3? Let's say that the cost for those chips drops 10 fold due to economy of scale. $5 is still a ton of lost profit on devices that are known for being sold at a loss. And that's all for an encoder chip capable of doing 1080p @ 30fps. What about 60 fps? What about 120 fps or 240 fps for the newer 120hz/240hz panels? What about the problems introduced when you run MPEG-2 compression on the text of the website I'm attempting to read with my networked video device?
On top of that, you still haven't addressed the problem of poor video compression, the reasons why we're even bothering to introduce lossy compression to an uncompressed video output signal in the first place, or the issue of codec stagnation when we're dealing with everything being transcoded to MPEG-2 in the end.
Finally, I still can't work out the problem you're trying to solve in the first place. You seem so intent on comparing a video output signal to a network cable that you can't tell me WHY you want to do this. You have a vague requirement of routing inputs to outputs, but we already have a system in place for that. Commercially available set top boxes such as the Apple TV, Popcorn Hour, and similar have been around for several years, and homebrew solutions have been around for longer than that. They all allow us to use existing home networks to send only the compressed video that's necessary, then layer their interface on top before outputting with regular video outputs. Got a video on device A but want to play it on TV B? We can just send the video file over an existing network. You want us jumping through hoops to decode the file at Device A (remember, it might not be in MPEG-2 or whatever format your system uses), layer our interface on top, re-encode to an MPEG-2 Transport Stream format, then send it to TV B. Or, we can have an inexpensive set top box at TV B, capable of handling any input format and without the necessary hardware to encode back to Transport Stream format. Then we just dump the framebuffer video out to a TV.
I won't lie, your system sounds incredibly appealing except for the edge cases. That's why it already exists. DTVs have been capable of doing EXACTLY what you're describing for at least 6 or 7 years over firewire. A standard exists to allow MPEG-2 Transport Streams over firewire from any device to any device, and it even supports simplistic menu systems. Hell, there's even a standard called that allows for a DTV to dump a tuned signal out to a firewire hard drive (provided the drive enclosure can speak the protocol necessary) for use as a tremendously inexpensive DVR. There's even a company that sells software that causes your computer to emulate the AVCHD system, and I'm sure someone could implement an OSS solution in a couple of weeks if they were bored and resourceful. Because there's plenty of bandwidth left on the firewire stream, it could even support DRM for the Hollywood crew. Firewire protocol over ethernet cabling is trivial to implement, and involves not much more than dropping in a box with a firewire port on one side and an ethernet port on the other.
It never caught on because it fails at the edge cases. Game systems require encoding hardware, computers require encoding hardware. Video transmitted in a format other than the MPEG-2 TS (like, say, everything except OTA DTV) requires decoding and encoding hardware. Face it: you want your television to be a thin client rather than a monitor, except instead of one central server you want every device to be capable of acting as a server. The minor upside (it's awesome and cheap for prerecorded video in MPEG-2 TS format) is completely outweighed by the myriad of downsides (it requires extra, expensive hardware for any device that isn't doing prerecorded video in MPEG-2 TS format, and it has poorer image quality for real-time video).