Here's my counter-argument in case you were serious.
Dimwit #1: 555's fail when hell freezes over. An engineering intern can make changes and see it work. The PCB will cost more than the electronics. 555 as a component will be available for years.
Dimwit #2: Arduino/ATMEGA are so well documented that the next engineer supporting this should have no problem making appropriate changes even 10 years from now, assuming Microchip sustains the ATMEGA product line.
Senior Software Developer: You've introduced an attack vector [the web interface], increased the BOM cost [the Linux board], programmed it in a language that changes on a yearly basis [node.js]. Not to mention having to provide a Linux image source programmable [preferably eMMC], and ensuring compatibility of the web config for major browsers for the lifetime of the product. All for a blinking LED.
Although I'd use a tiny micro or a blinking diode by now.
Dimwit #1: Ah, use a 555 timer.
Dimwit #2: Use an Arduino with the Blink sketch.
Senior Software Developer: I'll use a Linux board with a blink program running on Node.js. The blink program will watch for the alarm condition and blink the LED in response. The program will also provide a web based configuration interface. What if marketing changes the requirements from a simple blink pattern to:
blink blink (pause) blink blink (pause) etc...
The simple 555 timer approach would be too inflexible.
The arduino approach would require altering, recompiling and re-flashing the firmware.
The senior software developer approach would be sufficiently flexible that you could connect a web browser and reconfigure the blink pattern.
Each blink pattern can be given a name and saved. Such as the slow-blink, fast-blink, double-blink, etc. Each pattern consists of a list of on/off states associated with a duration in milliseconds. Anyone can point their browser to this and reconfigure new blink patterns that become popular.
What could possibly go wrong?