From an email of Thomas Pfeiffer:
Well actually, there is an easy way to make it absolutely clear which is which, although it takes lots of horizontal space and probably looks very ugly if you have many switches in the same UI: Just add text labels on each side, next to the button, not inside of it. E.g. "OFF" or "O" on the left side, "ON" or "I" on the right side. That makes things perfectly clear. So if ambiguity is the only reason against using switches on Desktop, we should use them. If you can make it clear on a touch screen, you can make it clear on a normal monitor. However, there may be more reasons than that.
Let us look at the issue more closely. First of all, switches are not merely the "touch version" of checkboxes. Some developers may use them that way, but they are not. They should be used for different purposes, and the GUI guidelines of systems that have both do make that clear (though interestingly, the decision criterion varies from platform to platform:
- The Android design guidelines make the following distinction: "Checkboxes allow the user to select multiple options from a set. Avoid using a single checkbox to turn an option off or on. Instead, use an on/off switch."
- The guidelines for BB10 go in a similar direction: "Use check boxes when users can select multiple items or options." "Use a toggle switch when users are choosing between two distinct options, such as Off and On. You can also use a toggle switch if you want to make a setting harder for users to change accidentally."
So according to the Android or Blackberry guidelines, the Battery Monitor should use a switch, whereas the Printer Manager should use checkboxes.
- The Meego UX guidelines (yes, Meego is dead but that doesn't mean their guidelines are bad) say the following: "Toggle switches are best used in system or applications settings, and are best suited to toggle a setting or mode that affects the whole system. Good examples are switching networking or silent mode on or off." "A checkbox works in the same way as a toggle switch, but it is more suitable to use for smaller settings, like a preference in an application"
So these guidelines would speak for using a switch in the Battery Monitor as well. Regarding the Printer Manager, it would be a question of interpretation.
- The Windows Store apps guidelines offer a distinction which I personally find the most logical: "Use a toggle switch for binary settings when changes become effective immediately after the user changes them." "Use a checkbox when the user has to perform extra steps for changes to be effective. For example, if the user must click a "submit" or "next" button to apply changes, use a check box."
The reason why I find this logical is that it relates to the real-world equivalent of checkboxes and switches. When I flick a switch, usually something happens immediately. On the other hand, checking a box on a paper form does not immediately change anything, it only has an effect after I submitted the form somewhere. And this is similar in the digital world: Checkboxes first appeared on digital forms, where changes only went into effect after the form was submitted. Therefore if we only use checkboxes for changes without immediate effect, users can be sure that changing the state of a checkbox won't do any immediate harm.
According to these guidelines, both Battery Monitor and Printer Manager would use switches.
So conceptually there is indeed a difference between a checkbox and a switch. Now, with that said, comes the big "but": All of these guidelines are for touch-based OSes. Looking at the guidelines for mouse/keyboard systems from the same vendors reveals a different picture.
Neither the OS X Human Interface Guidelines, nor the GNOME Human Interface Guidelines (Toggle Buttons are not the same as switches!), the Microsoft guidelines for desktop applications or the ChomiumOS guidelines contain any mention of switches. They all have only check boxes.
So why is that so, even though the criteria for using switches instead of checkboxes would apply in the desktop world as well? Unless someone here knows someone in the respective teams at these companies or digs up a blog post explaining the decision not to introduce switches in the desktop world, we can only speculate. One reason is surely that flicking a switch on a touch screen, though not "natural" at all because of the lack of haptical feedback, is much closer to reality than flicking a switch by clicking it with a mouse. Another reason is surely that accidentally clicking a checkbox with a mouse is much less likely than accidentally tapping it on a touch screen (which the BB10 guidelines mention as one argument for using a switch and which is also underlying the guideline from Microsoft).
Sure, Metro apps would display switches on the Desktop as well, and so does GNOME 3, but that's only because they're trying the "One size fits all" approach, which Plasma explicitly does not adopt (and if we look at the "success" of Windows 8 so far, I think that's a good decision). In their guidelines specific for desktop applications, both do not mention switches.
So, to summarize: The industry has mostly adopted a distinction between checkboxes and switches in the mobile world, but sticks with checkboxes only in the desktop world and I see no compelling reason for being the only environment that has switches in desktop-only UIs.
And If a developer works around the standard to display switches in his or her desktop UI, that UI should not become part of Plasma Desktop, unless we agree that we want switches in general (for a reason yet to be brought forth).
-  http://developer.android.com/design/building-blocks/switches.html
-  http://developer.blackberry.com/devzone/design/bb10/components.html
-  https://meego.com/sites/all/files/users/admin/meego_touch_ui_v1.2.pdf
-  http://msdn.microsoft.com/en-us/library/windows/apps/hh465475.aspx
-  http://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/Controls/Controls.html
-  https://developer.gnome.org/hig-book/stable/controls.html.en
-  http://msdn.microsoft.com/en-us/library/windows/desktop/aa511482.aspx
-  http://www.chromium.org/chromium-os/user-experience/ui-elements