Agree, but I think teleop and muxers in particular are a bit of a special case. They're so easy to write, and are a decent learning opportunity, so a lot of them get created by novices in the learning process, and then unwittingly made available as "universal" or "generic".
If you're integrating a robot and need either of these services, I encourage you to check out the
ros-teleop org on github.
Even within the org, there's slight repetition, but the basic idea is that joy_teleop and key_teleop are python-implemented and very flexible, able to publish any message based on configuration from a yaml file, whereas teleop_twist_joy is specifically for publishing twist messages, and is C++ implemented, intended to be able to easily compile into a larger "base robot" node.
The twist_mux package does what it says on the tin, and is similarly easy to embed into another process.
M.