To point out the English semantics: "can await things" is not synonymous with "will await things".

Just because an async method is able to return control to the owning thread for the time being (i.e. while awaiting something), doesn't mean that it invariably will do so.
As a basic example, if your code starts a task, performs some other work, and then awaits that task, it's possible that the task already finished by the time your code awaits it, which means that your code will never actually wait for the task to complete, it will immediately continue with the rest of its work.

Your ILight hits on this precise distinction. It enforces that any light which implements the interface must make their method awaitable. However, the interface does not in fact enforce that any light which implements the interface must actually await something.

Your approach is perfectly fine.

I've seen some people [..] say it's bad practice to have something return a task that is synchronous.

That statement does not account for cases like your example, where you're trying to define a blanket interface that accounts for both synchronous and asynchronous implementations.

If none of the implementations make use of await, be it in the method body or a submethod below it, then using async is indeed irrelevant.

Although even then you could still argue that introducing async is the first step of upgrading the library's contract to being async-friendly, before actually rewriting the method bodies themselves.

To point out the English semantics: "can await things" is not synonymous with "will await things".

Just because an async method is able to return control to the owning thread for the time being (i.e. while awaiting something), doesn't mean that it invariably will do so.
As a basic example, if your code starts a task, performs some other work, and then awaits that task, it's possible that the task already finished by the time your code awaits it, which means that your code will never actually wait for the task to complete, it will immediately continue with the rest of its work.

Your ILight hits on this precise distinction. It enforces that any light which implements the interface must make their method awaitable. However, the interface does not in fact enforce that any light which implements the interface must actually await something.

Your approach is perfectly fine.

I've seen some people [..] say it's bad practice to have something return a task that is synchronous.

That statement does not account for cases like your example, where you're trying to define a blanket interface that accounts for both synchronous and asynchronous implementations.

If none of the implementations make use of await, be it in the method body or a submethod below it, then using async is indeed irrelevant.

Although even then you could still argue that introducing async is the first step of upgrading the library's contract to being async-friendly, before actually rewriting the method bodies themselves.