The short answer is most likely no, a build.zig.zon manifest is required for build system dependencies.
The longer answer is, it depends on what is your definition of a dependency is in this context. If it’s a build system dependency that you expect to be able to resolve via b.dependency("foo", .{}) and subsequently obtain modules/artifacts from, then you definitely need a build.zig.zon.
The exception would be if it’s a “dumb tarball” of files and not a Zig package with a build.zig, in which case you could in theory create a small Zig program that takes an archive URL and an output directory as command-line args and fetches/extracts that archive to the specified output directory. You could then invoke that program with b.addRunArtifact in combination with std.Build.Step.Run.addOutputDirectoryArg to obtain LazyPath handles to the directory and/or its files. But all of this would almost certainly be both worse performing and more work for you than just using the package manager as intended.
Would you mind expanding upon why you feel an aversion toward having a build.zig.zon in the first place?
Don’t run imperative code that accesses the file system or the network directly from your build.zig. In the future, the build system will be sandboxed, and your build function will be prohibited from accessing system resources, so this is not future proof, and even now it’s a poor idea since the code will not take advantage of the build system cache and might be inadvertently invoked by innocuous things like zig build --help or tooling like ZLS. If you need to e.g. fetch something from the Internet, you should use a run step as described above. The only thing your build function should do is declaratively construct a (serializable) graph of build steps to be processed by a build runner.