I've been testing embedded devices since 1999, and I started from scratch as a manual tester and I'm now a full-time automated test software engineer developing both tests and systems/frameworks, so I hope I can offer a little perspective from my own viewpoint.
I started out testing credit card machines (entirely manually), moved to mobile phones (mainly air interface stuff initially, but I moved into automation during that time - and there was manual testing involved). Now I create automation test systems for TETRA radios (emergency radios - also used in oilrigs, mines etc. Hazardous environments.).
I've been a programmer longer than I've been a test engineer, so the programming side was always there, but when I started testing manually I realised how interesting testing was from the point of view of knowing the system under test.
When you test something manually and you have to raise a bug against it, you also want to raise it with the most detail possible - logs, reproduction scenario, etc. This means less work for you later, and the best possible start for the engineer working on the issue. Knowing the system under test is vital for this.
That set of skills means you are able to define actions, timings, and system setups which reproduce the issue. You need to codify the test, as it were.
If you're of a particular mindset (remember, I've been a programmer longer than a test engineer), then eventually you get interested in how to reproduce scenarios automatically, if only so you can easily retest or create regression scenarios you won't have to run yourself. You progress to looking at automation naturally (I certainly did).
In summary - if you start out in manual testing you're actually building towards working in automated test. So yes, manual testing is a good discipline to work in before working in automated test.