Absolutely! A honeypot can be part of an end-to-end form protection solution.
Just to be clear to others, Marketo doesn't have a built-in field designed as a honeypot (i.e, a hidden input or simply nondisplayed field that is expected to be left blank, and that would only have a value if the form is submitted by a simple posting bot). A custom field needs to be created for this, together with a non-destructive back-end flow. A more intelligent posting bot -- one whose behavior is modeled on an original human form submission -- won't be deterred by the honeypot approach.
To take it from the top: there are multiple* distinct types of unwanted marketing form posts (I'm distinguishing marketing applications from form posts in general, like in a comments section):
[1] Real, human leads providing fake information in an attempt to get your content without being marketed to afterward.
[2] Hackers/scammers providing the real information of other humans in order to target those victims in automated responses.
[3] Hackers providing malicious data, such as malware-distributing URLs, in hopes that the information is displayed to an impersonated lead on a personalized page. This is like [2] but doesn't require an autoresponder.
[4] Hackers posting purposefully suspicious-looking data in order to punish the lead they are impersonating. This one is why a back-end flow needs to be non-destructive: you must protect existing leads from deletion simply because a bad form was submitted in their name.
[5] High-volume automated posts with no actionable payload (because the data is never displayed elsewhere). These may be used for a DoS attack even if there is no other consequence.
A plugin like Etumos Verify (the form-integrated part, that is) deals specifically with case [1]. The assumption is the vast majority of otherwise valid leads who try -- at first -- to use non-emailable addresses or non-callable phone numbers will adapt to the restrictions of your form and switch to real contact info. Such services can also check if someone is using a domain that is known to provide disposable addresses (in an effort to create valid info that becomes invalid shortly afterward). Naturally, they cannot detect a just-set-up Gmail account that will never be checked, but they can detect addresses at the hundreds of known "disposable address" providers.
A honeypot field covers cases [2]-[4] well, as long as untrained bots are used. Where the honeypot stalls is when the honeypot logic is figured out by a human (which is easy since it must be in the view-source of the page). For this reason I prefer a reCAPTCHA widget over a honeypot field, since reCAPTCHA it is resistant to both dumb and smart bots: it is, I would say, unbottable.
Unfortunately, when [2]-[4] are executed by a large mass of humans (there are services the bad guys can hire for this) instead of by machines, both honeypot fields and reCAPTCHA fall down, since the form is indeed being filled out in a browser that executes JavaScript (so it obeys the honeypot rules, and the person can also complete the reCAPTCHA correctly). reCAPTCHA does have rate limits -- both hard limits enforced by the Google code and the implicit limit of how long it takes to choose the squares with a piece of pizza or what-have-you -- which make it relatively successful vs. a honeypot in these cases. But it still can be defeated by a sufficiently wide, real-life crew.
Case [5] is essentially unsolvable in "userland." Even if you can detect fake leads in a flow (either with a reCAPTCHA verification or honeypot emptiness check), the payload is the DoS itself against your instance, not the lead information. By the time the flow sees the data, the DoS is already in progress (and triggers that delete fake leads even increase the effectiveness of the DoS, which is a classic systems conundrum called a stampede that can be used in an amplifier attack). Marketo has set reasonable limits on the number of form posts per minute from a given IP, so there's not much more you can do yourself on this note. But one thing you shouldn't do is circumvent Marketo's protections by using an ungoverned server-side form post or an API-based form post. Both of these options make you trivially vulnerable to DoS attacks that wouldn't be successful otherwise.
* I could've gone on with [6] and more, but I decided to keep it short.
.png)