I agree, and I come from an old-school C and embedded background. If you do it in C, you have the opposite problem: interacting with the hardware is easy, speaking to a web API becomes a huge pain.
There's an "impedance mismatch", which has to be overcome somewhere. And computing power is getting cheaper and cheaper. We're at the point where if you have a little board in a case with some I/O connectors, the CPU will be the least expensive part. Casework and connectors will make up a surprisingly large part of the cost, often costing whole dollars!
Edit: also, debugging your C microcontroller program can be quite a pain, even once you have a correctly configured in-circuit debugger.
Coming also from a hardware design & embedded background, it was quite a surprise when I began to notice this a few years ago. I was so accustomed to processors being expensive that it was a shock to notice that as their prices dropped close to zero, it was the connectors and switches in my design that were becoming the expensive bits.
OTOH, CPUs are now so cheap they have become replacements for fixed logic devices.
Sure cpu's are cheap, but the thinking in the embedded world is still - i'm making 20K of this(or maybe a lot more) , and if i save 50cents on the cpu - this is $10K so management will like this savings, even if it takes some work.
But actually , if you can replace the physical UI with a phone based UI using a cheap bluetooth mcu and some framework like blynk or simblee ,than you'll have a decent ram/flash and a cheaper product.
> interacting with the hardware is easy, speaking to a web API becomes a huge pain.
Particle (particle.io) does a pretty nice job of bridging this gap in my experience. You still write code in C-like Wiring, but they have built-in APIs for storing data in the cloud and calling webhooks. It's not as simple as interacting with web apis from JS, and the fact that it relies on their cloud service would make me hesitate to use it in a commercial product. But for my home play projects, it provides a really nice balance of using C for the hardware stuff without making the networking stuff a major pain.
If you know C, you will love Arduino. It's very easy to "to speak to a web API". They are usually low power 8-bit CPUs with 16 MHz, exactly right for small projects like blinking some lights that should run on battery for years.
JavaScript/Python/etc on RaspherryPi or this new Mozilla thingy are interesting too, though will drain your battery faster. You need an OS on a 32bit CPU. If it's connected to the web you should also update the software stack.
Isn't it the opposite? If you aren't comfortable with C, Arduino has a simple enough API and good enough tutorials+documentation that you can still make it work.
If you are comfortable with C, just about everything is better than arduino because you'll get debugger support and full control over all the goodies like clocks, charge pumps, DMA controllers, asynchronous ADC operation, pin multiplexers, USB/Ethernet controllers, etc.
I live in the middle. For quickie little projects like my NMEA protocol converter, the Arduino tools & IDE are fine, if barely adequate as the project has grown.
However, I have another project where Atmel Studio is a better choice. So I import all the Arduino libraries I need (there's a plugin that can do this automatically, but it's buggy), and then just build it as a regular C++ project but I get "free" use of the libraries without the crappy Arduino IDE.
The nice thing about Arduino is it's so popular that the economies of scale let me buy hardware cheaper than I could build it myself and pretty much all the libraries I need are already written. Although I have had to debug a few of them!! The bad thing is their terrible interface that's really made for tiny programs only.
It depends what you want/need. Initially I thought like you too, I coded embedded C stuff years ago. Though for quick prototyping and hobby things, it's a lot faster to write C code with macros (=Arduino), you can put together a nice prototype in hours. If you want to sell your product, you can always rewrite it later.
I thought Arduinos didn't come with Ethernet on the chip, and instead you have a Heath-Robinson addon board which you speak SPI to another microprocessor which has the TCP/IP stack, MAC and PHY on?
The only thing I've seen that seems to really be viable for remote battery operation is the ESP2866. I have a Pi in my cupboard reading the electricity meter.
I really ought to learn Arduino, simply because it's so popular.
There several Arduino models that have an ethernet port on board and there is the official Ethernet Shield for other models like UNO, Mega. The Arduino standard library supports the common solutions out of the box. So no, you don't have to bother with low level stuff (but optionslly, you can write very low level C and shift registers and speak SPI directly, if you want).
There's an "impedance mismatch", which has to be overcome somewhere. And computing power is getting cheaper and cheaper. We're at the point where if you have a little board in a case with some I/O connectors, the CPU will be the least expensive part. Casework and connectors will make up a surprisingly large part of the cost, often costing whole dollars!
Edit: also, debugging your C microcontroller program can be quite a pain, even once you have a correctly configured in-circuit debugger.