I was looking at these option initially too, but ended up going for the challenge since, both I read some not-so-good reviews and shipping the thing to germany would probably ended up being at least as expensive as buying the soldering equipment :) Building one of those custom GamePaks takes about ~4 hours once you have all the materials prepared (you really need very, very thin wires!) and putting it together for the first time is one of those finger crossing moments which you'll remember for a really long time :)
A good question for any "macro" systems like this is something like the following:
1. Suppose you've written a function 'foo' in your language that does something useful (e.g.: partitions a sequence, validates a map, or pretty much anything really).
2. Some time later you want to write a macro 'bar'.
3. Can you use function 'foo' when writing 'bar'?
If the answer to 3 is "no" then you don't really have Lisp-like macros.
This is what makes Lisp macros so powerful. It's not just that you have a way to mangle abstract syntax trees. If that's all you want then yeah, you can write a parser and template language to do it, like this thing or sweet js, but it's not the same.
Lisp macros are beautiful because there's no real divide between "writing code" and "writing macros". It's all just code. You don't have to worry about which things are available in code-land and which are available in macro-land because they're the same place. There's just "the language" which you extend and mold with functions and macros woven together as necessary.
Contrast this with a language without real Lisp-like macros, like Clojurescript. If I want to write the 'bar' macro in Clojurescript I need to think "wait 'foo' is a Clojurescript function so now I need to port it back into Clojure land before I can use it in this macro because macros in Clojurescript live in Clojure-land not Clojurescript-land". I need to think about this for everything I call inside a macro.
(Admittedly the situation isn't as bad in Clojurescript because it's fairly close to Clojure in syntax and it's possible to cross-compile code so it lives in both "lands", but the ugly divide is still there.)
Common Lisp, Clojure, Scheme, Wisp, Julia, etc have Lisp-like macros. Sweet JS, Clojurescript, C, etc don't.
These types of macros are very similar to Scheme's syntax-rules macros without the hygiene.
Viewing Lisp macros as an arbitrary function from syntax to syntax is fine, but such macros are not very Scheme-y. It's very difficult to have such macros and guarantee they're hygienic, which is why syntax-rules limits you to matching patterns and producing templates -- it effectively limits the kinds of functions which can be macros.
Other types of Scheme macros (which are non-standard), like explicit renaming and syntactic closures, require programmers to opt-in to hygiene. syntax-case (which is in R6RS) allows programmers to break hygiene by jumping through hoops, but is otherwise similar to TFA's system as well.
So if Scheme is a Lisp and these macros are like Scheme macros, I don't think it's inaccurate to call them Lisp-like macros. But it is imprecise.
As an aside, I've written a compiler for a Lisp-like language. Speaking from experience, getting the compiler to answer "yes" to 3 is non-trivial (even though it's dead-simple in an interpreter). I suppose that's why Racket has all the phase distinctions it has.