I'm not sure this is obvious or even particularly well-publicized.
The "official recommendation" in the U.S. for many meds is that they be flushed down the toilet, especially scheduled/controlled substances. The FDA maintains a "flush list" [1] of medications that you are specifically instructed to dispose of by flushing. However, even for medications not on the official flush list, it's common to be informed by reasonable authorities that you should dispose of them by flushing -- e.g. I had to sign paperwork at my doctor's office affirming that I'd responsibly dispose of my unused ADHD meds by flushing them down the toilet before my dr would write the prescription. This was seconded by the drug/alcohol training I was given as a condition of attending college, which stated that you should flush all unused medication.
As a robotics engineer, I'm surprised how controversial "hardware can't remote" is turning out to be. Sure, some things can be done fully in simulation or by mailing everyone on the perception team a bunch of sensors. However, existing/popular simulators aren't that good at simulating things like odometry error, and if you're trying to do any object manipulation they're not great at anything beyond "before I run this on the robot, please make sure I'm not going to destroy things" (my understanding is that accurately simulating manipulation is hard because of the various frictional forces involved). And, of course, giving several employees a large, expensive KUKA arm to keep in their house or apartment is impractical on many levels. If people are running code remotely on a physical robot that's in the office, at least one person has to be in the office to keep an eye on it (for safety, and freeing the robot if it gets stuck). This is also not even getting into remote embedded, electrical, or mechanical work -- everything I've listed would affect a garden-variety software developer. So, yeah, I'll endorse "hardware can't remote", and will admit to some frustration with non-hardware-adjacent software engineers, who have a tendency to make over-broad generalizations about the feasibility of remote work.
A few other comments have mentioned the LEGO Mindstorms system, which is a great choice if you don't want to deal with hardware. If you go that route, I would strongly recommend using ev3dev [1] in order to avoid the LabVIEW-based programming language LEGO provides. You can get pretty far in the Mindstorms system, especially if you avoid LabVIEW; my biggest Mindstorms project was a 1v0 tabletop soccer robot using a subsumption controller. I will also note that if you're planning to teach controls at all (PID controllers are easy to implement, and are often used for controlling motor speed), Mindstorms can't really achieve a tight enough control loop; go with an Arduino-based system instead.
If you want something a little simpler than Mindstorms to get started with, you can also get a robot that holds a pen and is programmed in Logo [2]. Logo was designed as a language to teach programming to children, so it's very easy for kids to get started, and drawing on big sheets of paper with a pen immediately gives them the feeling of "doing something".
I would encourage you not to be scared of hardware :) You can build a lot of fun robot projects with cheap motors (you don't necessarily need servos), bump switches, and a cardboard-and-hot-glue chassis, using pretty simple circuits. The two classic beginner projects are wall-following and back-and-turn. At its simplest, a wall-following robot can use a switch touching the wall to control which of two motors turns on. A back-and-turn robot is a robot that backs up and turns in a different direction when it encounters an obstacle (and, if you leave it running long enough, will tend to escape whatever room you put it in). To avoid soldering, you could get started with a solderless breadboard (although make sure the wires don't get jostled out of place by robot collisions or falls).
It sounds like this is probably more advanced than your kids are ready for, but you could also get a Neato robot vacuum cleaner and control it with a Raspberry Pi running ROS [3] [4]. ROS (Robot Operating System) [5] is a very popular framework used by both professional robotics engineers and hobbyists; it's not the most beginner-friendly, but is useful for more advanced robotics software projects, and there's a large ecosystem of ROS packages for things like teleoperation and path planning. Neato vacuum cleaners specifically are great for this because they include a LiDAR, which lets you try out the SLAM and path planning packages provided by ROS.
My apartment's current A/V setup is an old third-hand projector I picked up for free pointed at a blank wall of our living room. The only thing I paid for was the serial cable so I could configure the correct input port, but even if I'd purchased the projector new it would run me about $150. In comparison, one of the article's top recommended dumb TVs is $450, while the other is "no longer available". Plus we can use a real computer with a keyboard sitting on our coffee table to control it instead of using the TV remote to painstakingly enter every character. Sure, we could have a less janky setup in many ways -- one day I aspire to build an actual wall shelf for the projector -- but the experience is miles better than any TV, smart or otherwise.
Trying to learn frontend so I can make myself a better to-do list/calendar app. I'm a robotics engineer so I have no idea what I'm doing, but it's fun. Due to executive dysfunction, I tend not to have a very good idea of how long it'll take me to finish anything longer than about a day's work (so I assume it "won't take that long", which fuels dangerous amounts of procrastination), so my concept was that each task gets broken down into subtasks that are small enough that I can estimate time for them. These time estimates then get propagated to the root task, and leaf-level tasks can be dragged and dropped into today's calendar (with other events pulled in from Google Calendar so I don't accidentally double-book myself). On the task itself I'll be able to record how much time (in pomodoros) it actually took to complete; in addition to tracking how I actually spent my time, hopefully this will help calibrate my future time estimates.
I also finished knitting a sweater -- my second overall, and first time not working from a pattern. I had to redo the yoke three times (the torso and front/back panels of the yoke are lace, so I wanted to integrate the decreases in the lace pattern), but I'm really satisfied with what I ended up with.
I'm not sure this is obvious or even particularly well-publicized.
The "official recommendation" in the U.S. for many meds is that they be flushed down the toilet, especially scheduled/controlled substances. The FDA maintains a "flush list" [1] of medications that you are specifically instructed to dispose of by flushing. However, even for medications not on the official flush list, it's common to be informed by reasonable authorities that you should dispose of them by flushing -- e.g. I had to sign paperwork at my doctor's office affirming that I'd responsibly dispose of my unused ADHD meds by flushing them down the toilet before my dr would write the prescription. This was seconded by the drug/alcohol training I was given as a condition of attending college, which stated that you should flush all unused medication.
[1]: https://www.fda.gov/drugs/disposal-unused-medicines-what-you...