>Layout of high-frequency electronics has many gotchas

I listened to this mantra for about 15 years but its like anything else that "looks hard" it becomes obvious after doing it.

RF design rules are well documented and pretty straightforward once you get past the smoke, mirrors and doom mongering. All the good RF subsystem manufacturers have white papers, dev boards and fully documented layout design guides for their chips and low power ISM sub-systems under 20dBM are more or less bulletproof.

I have made several commercial designs, my first ones were just copy/pasting the gerbers off the dev boards (I did not even need to buy the dev boards as the gerbers were downloadable for free) all these worked fine and even several dBM of transmission loss due to bad RF or enclosure design is not actually a game changer in most short distance/low power applications.

My first designs I actually understood very little, now I have all the toys to do proper RF design and understand it much better and so long as you read up on the basics there is no reason not to try too. Seriously it costs $15 for a PCB delivered worldwide these days so you can afford to experiment or tell your EE/intern to do it and dont be too surprised when it works.

Arduinos powered by AVRs aren't high-frequency. The highest-frequency external component might be a 20mhz crystal, which you can lay out just by following the example design in the data sheet.

Most ARMs up to even a few hundred MHz are also pretty easy to lay out.

For wireless you're right, but this is more or less solved by the recent proliferation of cheap plug-in wireless modules that are already certified.

Using a module or not, you still have to go through unintentional radiator testing, though, right (if you have a clock signal on the board over some ludicrously low frequency)?

Yes, if you want to sell your device you will need to go through Part 15 testing. I think the limit is in something like low-digit kHz.

You're right that Arduinos are slower. I had things like the Raspberry Pi in mind.

The Raspberry Pi will be easier to layout than an equivalent ARM SoC that needs external RAM.

I really don't get the point of Android things. Looking at their website the most constrained device they support is on the order of a raspberry pi. Why wouldn't you just go with Linux/Raspbian in that scenario instead of locking yourself into Google?

There are many factors. To start, many companies were already choosing to run a fork of Android in their products, like the Amazon Echo. This gives you access to Android's APIs, developer tools, and knowledge base, which is a significant boost in productivity. By using Android Things specifically, you also get hassle-free OTA updates directly from Google, which is essential for security.

Raspbian is pretty much only supported on Raspberry Pis, so I think the worry of lock-in is worse there; and it's significant, taking into account that it's harder to go from prototype to production with a Raspberry Pi than with a SoM-based board.

The UserDriver system is another factor: Android already does sensor fusion, so if your product uses, say, a GPS receiver, you can hook it up to the OS with a short amount of user-space Java code, and all existing Android code that uses the location APIs now works with your GPS. No need to modify client code nor compile anything into the OS. And your UserDriver works on any Android Things system.

The talks of this year's Google I/O explain these kind of things in more detail.