Generally HTTP REST works on the idea of resources and properties.

so: /lights /lights/light-id /lights/light-id/wattage (return wattage of light)

Doing something like:

/lights/light-id/book-janitor-to-replace which might email and update the janitor's calendar/ToDo list, isn't really following the existing API design.

What do you mean "following the existing API design"?

A good API imo would hide the janitor's calendar/ToDo list unless it was absolutely necessary for the client to access it directly. Then an argument could be made in favor of the booking janitor endpoint on a light - and the API is no less RESTful.

Edit: I don't like it when people over-emphasize resources when talking about REST. I blame this practice on Rails being many people's first introduction to REST. But Rails isn't actually RESTful per Fielding. I prefer to use the term resourceful API to describe the kind of API Rails prescribes. REST is generally in favor of custom endpoints that hide complexity from the client, even at the expense of having a clear cut decision on eg. POST vs PUT/PATCH for a given endpoint.

I only bring this up because this is the topic of the article; that may be "REST as people talk about it" but none of that has anything to do with "what RESTful actually means".