TL;DR It's up to the developer to pick which pieces of the app are signed and whether or not tampering with those pieces results in any actions when the app is launched. You have to use trial and error to figure it out on an app-by-app basis.
It is largely up to the developer to decide which components in their application bundle are represented in the seal that gets signed before they deliver their application. Anything in the seal is effectively tamper-proof as it's mostly impossible to modify these things without changing their hash signatures. But that's doesn't actually mean you can't tamper with them.
The Apple Developer guide has this to say about what you should sign:
You should sign every executable in your product, including
applications, tools, hidden helper tools, utilities and so forth.
Signing an application bundle covers its resources, but not its
subcomponents such as tools and sub-bundles. Each of these must be
signed independently.
If your application consists of a big UI part with one or more little
helper tools that try to present a single face to the user, you can
make them indistinguishable to code signing by giving them all the
exact same code signing identifier. (You can do that by making sure
that they all have the same CFBundleIdentifier value in their
Info.plist, or by using the -i option in the codesign command, to
assign the same identifier.) In that case, all your program components
have access to the same keychain items and validate as the same
program. Do this only if the programs involved are truly meant to form
a single entity, with no distinctions made.
A universal binary (bundle or tool) automatically has individual
signatures applied to each architecture component. These are
independent, and usually only the native architecture on the end
user's system is verified.
In the case of installer packages (.pkg and .mpkg bundles), everything
is implicitly signed: The CPIO archive containing the payload, the
CPIO archive containing install scripts, and the bill of materials
(BOM) each have a hash recorded in the XAR header, and that header in
turn is signed. Therefore, if you modify an install script (for
example) after the package has been signed, the signature will be
invalid.
You may also want to sign your plug-ins and libraries. Although this
is not currently required, it will be in the future, and there is no
disadvantage to having signatures on these components.
Depending on the situation, codesign may add to your Mach-O executable
file, add extended attributes to it, or create new files in your
bundle's Contents directory. None of your other files is modified.
Also from here it's not necessarily true that having an invalid signature for an application means it will fail to launch. The page says:
It is up to the system or program that is launching or loading signed
code to decide whether to verify the signature and, if it does, to
determine how to evaluate the results of that verification.
An application may choose to allow modifications.
Your best bet is a trial-and-error approach with any application you're trying to modify. It may work, it may not. There's no always-true answer that can be given.
If an app has been signed you can look for a Contents/CodeResources file or a Contents/_CodeSignature/CodeResources file in the bundle. This file lists all the signed components and their expected hash values in the bundle. It's a good place to start understanding what pieces of the application a developer deems critical enough to watch for changes.
Best Answer
Basically ad-hoc signing in this context means that the binary is signed without any cryptographic proof at all.
In essence normally binaries are signed by adding a so-called CMS (a cryptographic message) where the hash of the CodeDirectory is the message that is signed by the signing identity. This means that an outsider can verify that the code was indeed signed by someone holding the private key for that identity.
When running programs, the macOS system can verify that these signatures are valid, and that it trusts the signing identity - and if it does, run the program. This is the basics of the GateKeeper functionality.
Ad-hoc signed binaries are vastly different as they contain no such CMS. Instead it simply holds the SHA-1 hash value of the CodeDirectory without any cryptographic proof of its validity, and no path of certificates/identities to verify against.
The CodeDirectory is an object that describes a particular instance of static code by having hash values for various pieces of code that the application is made from. By ensuring that the CodeDirectory is untampered by verifying the cryptographic signature, and that the various code bits of the application match the hash values stored in the directory, you can ascertain that the code wasn't tampered with.
Without the cryptographic proof this "untampered" check cannot be performed in the normal way.
Instead ad-hoc signed binaries are checked by comparing the SHA-1 hash value against a list of "known good" hash values stored in the static trust cache inside the kernel.
In essence this means that the "significant restrictions" placed upon any application you ad-hoc sign yourself is that it won't pass any kind of verification anywhere. It basically be the same as a non-signed binary.
However, if you're Apple, you can create applications that aren't codesigned in the ordinary way, and are instead explicitly trusted by the kernel. I.e. if for example Apple wants to ensure that an application is untampered when run at an early stage in system startup where the full signing identity verification is not up and running (or is unavailable) they can use ad-hoc signing. These applications can always be verified by the static trust cache, no matter if your certificate repository is hosed or anything like that.
In practice creating ad-hoc signed binaries is only of practical value for Apple developers.
You can find minor documentation on ad-hoc signing in Apple's developer section. For example:
https://developer.apple.com/documentation/security/seccodesignatureflags/kseccodesignatureadhoc
But you can also find snippets of documents in the source code for the codesign utility itself, and in the source code for libsecurity.